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1 .  Overview 

The  Department  of  Defense  (DoD)  established  the  Advanced  Distributed  Learning 
(ADL)  Initiative  to  develop  a  DoD-wide  strategy  for  using  learning  and  information 
technologies  to  modernize  education  and  training.  To  leverage  existing  practices, 
promote  the  use  of  technology-based  learning,  and  provide  a  sound  economic  basis  for 
investment,  the  ADL  initiative  has  defined  high-level  requirements  (e.g.,  content 
reusability,  accessibility,  durability,  and  interoperability)  for  learning  content. 

This  document  attempts  to  define  a  reference  model  for  sharable  courseware 
“objects”(SCOs)  that  meet  ADL  high-level  requirements.  It  should  be  possible  to  map 
existing  learning  models  and  practices  to  this  reference  model  so  that  common  interfaces 
and  data  can  be  defined  and  standardized  across  courseware  management  systems  and 
development  tools. 

1. 1  Status  of  the  Sharable  Courseware  Object  Reference  Model 
(SCORM) 

The  release  of  this  document  completes  the  initial  drafting  and  review  of  early-stage 
Web-based  learning  specifications.  With  this  release,  the  ADL  Initiative’s  SCORM 
enters  a  test  and  evaluation  phase,  during  which  researchers  and  early  adopters  are 
encouraged  and  expected  to  develop  trial  implementations  based  on  these  specifications. 
During  this  testing  phase,  corrections,  clarifications,  and  improvements — based  on  the 
trial  implementations — will  be  gathered  and  redistributed  for  review. 

In  parallel  with  the  testing  phase,  which  is  expected  to  take  4-to-6  months,  the  ADL 
Collaboration  Laboratory  (ADL  Co-Lab)  plans  to  release  example  implementations, 
addenda  to  this  document,  and,  at  the  end  of  the  phase,  a  suite  of  conformance-test 
software.  These  products  will  permit  content  and  tool  developers  to  verify  that  their 
work  products  conform  to  the  SCORM  specification  and  are  reusable,  interoperable, 
accessible,  and  durable. 


It  is  critically  important  for  readers  to  understand  that  the  specifications  contained  or 
referenced  herein  are  largely  untested  in  practice.  Although  example  implementations 
supporting  these  specifications  are  available  and  several  organizations  have 
implemented  portions  of  the  SCORM,  these  specifications  have  not  been  deployed  as  a 
system  or  as  a  fully  supported  product. 


1.2  Accelerating  the  Process 

The  purpose  of  the  ADL  Initiative,  among  other  things,  is  to  accelerate  the  development 
and  adoption  of  technical  specifications  that  promote  sharable  content  and  systems. 
Thus,  this  release  is  designed  to  encourage  rapid  trial  implementations,  incorporate  the 
findings  of  those  participating,  and  share  results  with  as  wide  an  audience  as  possible — 
all  in  “Internet  time.” 
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We  expect  some  organizations  to  adopt  elements  of  the  SCORM  specifications 
immediately  to  take  early  advantage  of  the  benefits  of  a  common  approach.  These 
organizations  will  necessarily  accept  the  risk  that  some  aspects  of  the  specifications  may 
change  as  experience  through  implementations  is  gained.  Of  course,  those  who  accept 
the  risk  early  on  stand  the  likelihood  of  being  farther  up  the  learning  curve  than  those 
who  wait,  and  early  adopters  can  influence  the  resolution  of  ambiguities  that  may  exist. 

1.3  Specification  Evolution  and  Example  Code 

The  release  of  SCORM  1.0  indicates  the  belief  that  the  specifications  are  as  stable  as  they 
can  be  before  being  tested  through  trial  implementations.  The  release  of  Version  1.0 
includes  a  suite  of  examples  that  implement  various  parts  of  the  specifications.  These 
examples  are  provided,  without  cost  or  restriction,  to  accelerate  more  sophisticated 
implementations.  Those  who  review  or  use  the  code  examples  are  encouraged — but  not 
required — to  provide  to  the  ADL  Initiative  feedback  and/or  other  code  examples  that  can 
be  shared  with  others.  In  this  way,  the  specifications  will  become  more  complete  and 
accurate,  and  test-development  software  will  become  robust. 

Through  this  process,  the  ADL  Initiative  will  provide  interim  releases  (e.g.,  Versions  1.1, 
1.2)  that  clarify,  amplify,  and  generally  improve  the  usability  of  these  specifications. 
When  this  process  has  stabilized  in  roughly  4  to  6  months  and  conformance  software  has 
been  completed  and  tested  by  the  ADL  Co-Lab,  a  “final”  version,  probably  “2.0,”  will  be 
released. 

We  hope  and  expect  that  the  changes  made  during  this  test  phase  will  not  significantly 
change  the  intent  or  technical  approach  of  Version  1.0.  Changes  that  impede 
implementation  or  are  determined  to  be  outright  oversights  will  be  incorporated  into 
Version  1.1.  New  topics  that  expand  the  overall  scope  of  the  SCORM  will  be  added  if 
they  are  judged  to  be  appropriate  and  stable.  Other,  more  comprehensive  changes  will  be 
included  in  later  versions  of  the  SCORM. 
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2.  Goal 

A  key  ADL  requirement  for  learning  content  is  the  ability  to  reuse  instructional 
components  in  multiple  applications  and  environments  regardless  of  the  tools  used  to 
create  them.  This  requires,  among  other  things,  that  content  be  separated  from  context- 
specific  runtime  constraints  so  that  it  can  be  incorporated  into  other  applications.  For 
reuse  to  be  possible,  content  must  also  have  common  interfaces  and  data.  This  document 
attempts  to  specify  a  reference  model  that  abstracts  runtime  constraints  and  defines  a 
common  interface  and  data  scheme  for  reusable  content. 

2.1  Rationale 

2.1.1  The  Need  for  Competency 

Government,  industry,  and  academia  are  experiencing  a  revolution  of  unprecedented 
proportions  in  science  and  technology.  This  revolution  and  the  advances  it  presents  pose 
significant  challenges  and  opportunities.  Organizations  must  adopt  these  advances  and 
leverage  them  if  they  are  to  compete  successfully  in  the  21st  century;  however,  infusing 
technology  in  routine  operations  increases  the  demand  for  people  who  can  deploy, 
operate,  and  maintain  it  competently.  Despite  the  increasing  presence  of  technology, 
competent  human  performance  remains  as  essential  as  ever,  and  its  ready  availability  is  a 
matter  of  the  first  importance  in  all  sectors  of  the  economy. 

Fortunately,  technology  also  provides  the  means  to  meet  the  challenges  it  presents.  As 
new  instructional  technologies  emerge,  they  provide  opportunities  for  universally 
accessible  and  effective  life-long  learning.  These  technologies  extend  learning  beyond 
the  confines  of  traditional  classrooms  to  encompass  homes,  workplaces,  and  community 
resources,  such  as  museums  and  libraries.  They  extend  beyond  the  traditional  school-age 
population  to  support  a  nation  of  life-long  learners. 

These  considerations  have  led  to  a  vision  that  guides  the  work  of  the  ADL  Initiative: 

To  ensure  all  Americans  access,  anytime  and  anyplace,  to  high-quality  education 
and  training  tailored  to  their  individual  learning  and  workplace  needs. 

2.1.2  The  Value  of  Tailored  Instruction 

Empirical  studies  have  raised  national  interest  in  employing  education  and  training 
technologies  that  are  based  on  the  increasing  power,  accessibility,  and  affordability  of 
computer  and  networking  technologies.  These  studies  suggest  that  the  promise  of 
training  technologies  [e.g.,  computer-based  instruction  (CBI),  interactive  multimedia 
instruction,  and  intelligent  tutoring  systems]  keys  on  their  ability  to  tailor  instruction  to 
the  needs  of  individuals.  In  contrast  to  classroom  learning,  these  approaches  enable  the 
pace,  sequence,  content,  and  method  of  instruction  to  better  fit  each  student’s  learning 
style,  objectives,  and  goals. 
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These  technologies  allow  individually  tailored  training  to  be  delivered  anytime, 
anywhere,  and  to  anyone  who  needs  it.  Such  accessibility  pays  off  for  the  individual  who 
wishes  to  advance  knowledge,  skill,  and  career  opportunities  and  for  the  organization  that 
depends  on  the  individual’s  growing  competencies  to  compete  successfully  in  the  global 
marketplace. 

Research  has  supported  the  intuitive  appeal  of  technology-based  instruction.  The  speed 
with  which  individuals  can  progress  through  instruction  has  been  found  to  vary  by  factors 
of  three  to  five  (or  even  as  much  as  seven),  even  in  classes  of  carefully  selected  students.1 
On  average,  a  student  in  classroom  instruction  asks  about  0. 1  questions  an  hour.2  In 
individual  tutoring,  students  may  ask  or  be  required  to  answer  as  many  as  120  questions 
an  hour.  The  achievement  of  individually  tutored  students  may  exceed  that  of  classroom 
students  by  as  much  as  two  standard  deviations — an  improvement  roughly  equivalent  to 
raising  the  performance  of  50th  percentile  students  to  that  of  98th  percentile  students.3 

The  dilemma  presented  by  individually  tailored  instruction  is  that  it  combines  an 
instructional  imperative  with  an  economic  impossibility.  With  few  exceptions,  one 
instructor  for  every  student — despite  its  advantages — is  not  affordable.  The  promise  of 
instructional  technology  is  that  it  can  provide  most  of  the  advantages  of  individualized 
instruction  at  affordable  cost  while  maintaining  consistent,  measurable,  high-quality 
content. 

2.1.3  The  Effectiveness  of  Technology-Based  Instruction 

Studies  have  shown  that  technology-based  instruction  may  significantly  reduce  the  costs 
(by  30-60  percent )  of  achieving  a  wide  range  of  instructional  objectives.  These  studies 
have  also  found  that  it  either  reduces  the  time  to  achieve  given  instructional  objectives  by 
about  30  percent  or  that  it  increases  student  skills  and  knowledge  by  about  30  percent, 
depending  on  whether  achievement  or  time  is  held  constant. 

The  value  of  these  capabilities  in  reducing  direct  training  costs  is  obvious.  The  savings 
accrued  through  improved  management  of  indirect  costs,  such  as  productivity  and  time 
away  from  a  job  site,  are  more  difficult  to  quantify  and  capture  but  are  equally  significant 
when  determining  the  full  return  on  investments  in  instructional  technologies. 

For  instance,  reducing  by  30  percent  the  time  to  train  just  40  percent  of  all  DoD  students 
in  specialized  skill  training — which  excludes  other  categories  such  as  recruit  training, 
pilot  training,  unit  training,  and  field  exercises — could  potentially  save  the  DoD  over 
$500  million  annually. 


1  Gettinger,  M.  (1984).  Individual  differences  in  time  needed  for  learning:  A  review  of  the  literature. 
Educational  Psychologist,  19,15-29. 

2  .  . 

"  Graesser,  A.  C.,  &  Person,  N.  K.  (1994).  Question  asking  during  tutoring.  American  Educational 
Research  Journal,  31,  104-137. 

3 

Bloom,  B.S.  (1984).  The  2  sigma  problem:  The  search  for  methods  of  group  instruction  as  effective  as 
one-to-one  tutoring.  Educational  Researcher,  13,4-16. 
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Given  these  potential  cost  savings,  a  reasonable  question  to  ask  is  whether  training 
effectiveness  is  being  lost  to  achieve  them.  Figure  2-1  shows  results  aggregated  from 
empirical  comparisons  of  technology-based  training  with  conventional  classroom 
instruction.  As  this  figure  shows,  233  such  studies  of  conventional  CBI  averaged  an 
improvement  in  learning  of  about  0.39  standard  deviations.  Adding  multimedia 
capabilities  also  adds  effectiveness,  raising  the  improvement  to  0.50  standard  deviations. 
Intelligent  tutoring  systems  intended  to  emulate  more  directly  one  teacher  interacting 
with  one  student  and  allowing  either  the  student  or  the  computer  to  ask  questions 
increases  the  improvement  to  0.84  standard  deviations.  Some  recent  assessments  of 
intelligent  tutoring  systems  yielded  improvements  averaging  about  1.05  standard 
deviations.  We  have  not  yet  met  the  2.00  standard-deviation  challenge,  but  the  trends  are 
promising. 
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Figure  2-1 .  Some  Effect  Sizes  for  Technology-Based  Instruction 

2.1.4  Promoting  the  Use  of  Technology-Based  Instruction 

There  is,  then,  evidence  that  technology-based  instruction  can  lower  training  costs  and,  at 
the  same  time,  increase  instructional  effectiveness  for  a  variety  of  training  objectives  and 
programs.  Yet,  its  use  is  only  beginning.  For  instance,  data  collected  suggest  that  less 
than  5  percent  of  DoD  training  programs  routinely  use  interactive  training  technologies. 
Technology  insertion,  as  is  often  the  case  with  new  applications,  may  depend  on  issues 
that  are  more  structural  and  organizational  than  technological.  Accounting  categories, 
local  incentives,  personnel  policies,  and  training  procedures  must  be  changed  to  make  the 
best  use  of  these  new  training  capabilities. 

Despite  these  difficulties,  the  benefits  of  technology-based  instruction  are  increasingly 
recognized,  and  initiatives  are  being  undertaken  to  increase  its  use.  Primary  among  these 
is  the  ADL  Initiative.  The  aim  of  this  initiative  is  to  increase  the  efficiency  of 
investments  in  technology-based  instruction  through  the  development  of  Web-available, 
“sharable  courseware  objects,”  or  SCOs.  These  SCOs  would  be  reusable  in  the 
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development  of  technology-based  instruction,  portable  across  different  presentation 
platforms,  accessible  through  the  use  of  metadata  standards  for  identifying  and  locating 
them,  and  durable  across  different  versions  of  operating  systems,  browsers,  and  other 
supporting  systems  software. 

This  DoD  initiative  is  being  undertaken  in  cooperation  with  the  Military  Departments  and 
the  Office  of  Science  and  Technology  Policy  (OSTP),  which  plans  to  extend  the  ADL 
approach  across  all  Federal  training  programs.  The  private  sector  involved  in  producing 
technology-based  instructional  systems  and  solutions  and  academia  are  also  expected  to 
adopt  the  ADL  approach. 

2.2  The  Need  for  a  Reference  Model 

Successful  implementation  of  the  ADL  initiative  will  require  guidelines  that  are  shared 
and  observed  by  organizations  that  have  a  stake  in  the  development  and  use  of 
instructional  technology  materials.  The  ultimate  form  and  status  of  these  guidelines 
remain  to  be  determined.  They  may  be  international  or  national  standards,  agreed  upon 
practices,  recommendations,  or  de  facto  practices. 

If  these  guidelines  are  to  be  articulated  and  implemented  successfully,  they  must  be  based 
on  a  common  “reference  model.”  This  model  will  not  replace  the  detailed  models  of 
instructional  system  design  or  practice  that  have  been  devised  and  adopted  by  specific 
organizations,  such  as  those  of  instructional  developers,  instructional  tool  developers,  or 
customers  associated  with  particular  industries  or  the  Armed  Forces.  Instead,  the  purpose 
of  the  reference  model  is  to  describe  an  approach  for  developing  instructional  material  in 
sufficient  detail  to  permit  guidelines  for  the  production  of  SCOs  to  be  articulated  clearly 
and  implemented. 

2.3  Reference  Model  Criteria 

There  are  three  primary  criteria  for  such  an  SCO  reference  model.  First,  as  stated 
previously,  the  criteria  must  fully  support  articulation  of  guidelines  that  can  be 
understood  and  implemented  for  the  production  of  SCOs.  Second,  the  criteria  must  be 
adopted,  understood,  and  used  as  much  as  possible  by  a  wide  a  variety  of  stakeholders, 
such  as  courseware  and  courseware  tool  developers  and  their  customers.  Third,  the 
criteria  must  permit  mapping  of  any  stakeholder’s  specific  model  for  instructional 
systems  design  and  development  into  itself.  Stakeholders  must  be  able  to  see  how  the 
reference  model  they  hold  in  common  reflects  their  own  model  of  instructional  system 
design. 

Applications  of  information  technology  have  been  shown  to  increase  the  effectiveness 
and  the  efficiency  of  training;  however,  up-front  investment  is  required  to  develop  and 
convert  training  materials  for  technology-based  presentation.  These  investment  costs  can 
be  reduced  by  an  estimated  50-80  percent  through  the  use  of  SCOs  that  are: 

•  Durable — do  not  require  modification  as  versions  of  system  software  change 

•  Interoperable — operate  across  a  wide  variety  of  hardware,  operating  systems,  and 
Web  browsers 
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•  Accessible — can  be  indexed  and  found  as  needed 

•  Reusable — can  be  modified  and  used  by  many  different  development  tools. 

Procedures  for  developing  such  courseware  objects  are  within  the  state-of-the-art,  but 
they  must  be  articulated,  accepted,  and  widely  used  as  guidelines  by  developers  and  their 
customers.  These  goals  can  only  be  achieved  through  collaborative  development. 
Collaboration  will  also  increase  the  number,  quality,  and  per  unit  value  of  courseware 
objects  made  available.  Such  collaboration  requires  agreement  upon  a  common  reference 
model. 
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3.  SCO  Reference  Model 


This  section  provides  a  high-level  overview  of  the  scope  and  purpose  of  the  SCORM. 
Subsequent  sections  define  technical  details  for  implementing  each  aspect  of  the  model. 


3. 1  Defining  a  “Learning  Management  System”  (LMS) 

LMS  is  used  as  a  catch-all  term  throughout  this  document  to  refer  to  a  suite  of 
functionalities  designed  to  deliver,  track,  report  on,  and  administer  learning  content, 
student  progress,  and  student  interactions.  The  term  LMS  can  apply  to  very  simple 
course  management  systems  or  highly  complex,  enterprise- wide  distributed 
environments.  Figure  3-1  shows  a  broad  definition  of  LMS  as  a  suite  of  server-side 
functionalities  that  controls  the  delivery  and  tracking  of  learning  content  to  a  client-side 
student. 


Figure  3.1.  An  LMS 

Note  for  Figure  3-1 :  The  SCORM  does  not  specify  functionality  within  the  LMS.  Only  Course 
Interchange,  Metadata,  and  Runtime  Environment  are  “in  scope”  for  this  version  of  the  SCORM. 

Many  participants  in  the  development  of  learning  technology  standards  now  use  the  term 
LMS  instead  of  “Computer-Managed  Instruction”  (CMI).  In  this  way,  they  can  include 
new  functionalities  and  capabilities  that  have  not  historically  been  associated  with  CMI 
systems,  such  as  back-end  connections  to  other  information  systems,  complex  tracking 
and  reporting,  centralized  registration,  online  collaboration,  and  adaptive  content 
delivery. 
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The  term  LMS  is  now  being  used  as  a  “superset”  description  of  many  possible 
capabilities.  Within  the  SCORM  context,  implementations  are  expected  to  vary  widely. 
SCORM  focuses  on  key  interface  points  between  content  and  LMS  environments  and  is 
silent  about  the  capabilities  provided  within  a  particular  LMS. 

Within  the  SCORM  context,  the  term  LMS  implies  a  server-based  environment  in  which 
the  intelligence  resides  to  control  the  delivery  of  learning  content  to  students.  In  other 
words,  in  the  SCORM,  the  LMS  has  the  “smarts”  about  what  to  deliver  and  when,  and 
tracks  student  progress  through  the  learning  content. 

Learning  content,  therefore,  does  not  play  a  “management”  role  in  the  SCORM  because 
that  function  falls  entirely  within  the  LMS.  That  means  that  SCORM  content  does  not 
determine  (on  its  own  on  the  client-side)  how  to  navigate  through  a  course  or  when  a 
student  has  completed  a  section  of  the  course.  That  is  the  LMS’s  job.  This  approach  frees 
content  from  course-specific  constraints  and  permits  the  development  of  content  that  is 
reusable,  sharable,  and  as  context  independent  as  possible. 

3.2  Overview  of  SCO  Reference  Model  (Narrative) 

The  SCORM  defines  a  Web-based  learning  “content  model.”  At  its  simplest,  it  is  a  set  of 
interrelated  specifications  designed  to  meet  DoD’s  high-level  requirements  for  Web- 
based  learning  content:  reusability,  accessibility,  durability,  and  interoperability. 

The  work  of  the  ADL  Initiative  in  developing  the  SCORM  is  also  a  process  of  knitting 
together  disparate  groups  and  interests.  We  hope  that  this  reference  model  will  serve  as  a 
bridge  from  general  emerging  technologies  to  commercial  implementations. 

Several  organizations  have  been  working  on  different,  yet  highly  related  aspects  of  Web- 
based  learning  technology.  These  work  areas  have  coalesced  into  three  major  topics: 
metadata,  runtime  environment,  and  course  interchange.  Although  these  evolving  areas 
have  made  great  strides  recently,  they  have  not  yet  been  “connected”  to  one  another  in  a 
meaningful  way.  In  some  cases,  emerging  specifications  are  quite  general,  anticipating  a 
wide  variety  of  implementations  by  various  user  communities  (e.g.,  metadata).  In  other 
cases,  the  specifications  are  rooted  in  earlier  CMI  practices  and  require  adaptation  to 
Web-based  applications. 

The  SCORM’ s  purpose  is  to  apply  current  technology  developments  to  a  specific  content 
model  and  to  produce  recommendations  for  consistent  implementations  by  the  vendor 
community.  These  technology  developments  come  from  groups  such  as  the  Instructional 
Management  Systems  (IMS)  Project,  the  Aviation  Industry  CBT  Committee  (AICC),  and 
the  Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  Learning  Technology 
Standards  Committee  (LTSC). 

The  scope  of  the  SCORM  is  not  all  inclusive.  A  host  of  issues  are  not  addressed  by  this 
version  of  the  document.  We  expect  that  the  scope  will  be  enlarged  over  time  and  the 
reference  model  will  be  expanded  as  experience  is  gained  through  implementation  and 
deployment. 

This  version  of  the  SCORM  comprises  three  major  elements: 
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1.  Course  Structure  Format.  An  Extensible  Markup  Language  (XML)-based 
representation  of  a  course  structure  that  can  be  used  to  define  all  the  course 
elements,  structure,  and  external  references  necessary  to  move  a  course  from  one 
LMS  environment  to  another  (see  Section  5  of  this  document). 

2.  Runtime  Environment.  A  definition  of  runtime  environment  that  includes  a 
specific  launch  protocol  to  initiate  executable  Web-based  content,  a  common 
content-to-LMS  application  program  interface  (API),  and  a  data  model  defining 
the  data  exchanged  between  an  LMS  environment  and  executable  content  at 
runtime  (see  Section  6  of  this  document). 

3.  Metadata.  A  mapping  and  recommended  usage  of  IEEE  LTSC  metadata 
elements  for  each  of  the  following  SCORM  categories  (see  Section  7  of  this 
document): 

a.  Raw  media  metadata.  A  definition  of  metadata  that  can  be  applied  to  so- 
called  “raw  media”  assets,  such  as  illustrations,  documents,  or  media  streams, 
that  provide  descriptive  information  about  the  raw  media — independent  of 
courseware  content.  These  metadata  are  used  to  facilitate  reuse  and 
discoverability  principally  during  content  creation  of  such  media  elements 
within,  for  example,  a  media  repository. 

b.  Content  metadata.  A  definition  of  metadata  that  can  be  applied  to  Web-based 
content  “chunks”  that  provide  descriptive  information  about  the  content — 
independent  of  a  particular  course.  These  metadata  are  used  to  facilitate  reuse 
and  discoverability  of  such  content  within,  for  example,  a  content  repository. 

c.  External  course  metadata.  A  definition  for  external  metadata  that  describes  a 
course  package  for  searching  (enabling  discoverability)  within  a  courseware 
repository  and  providing  descriptive  information  about  the  course. 

3.3  High-Level  Requirements  and  SCORM  Scope 

This  SCORM  document  frequently  references  the  following  high-level  ADL 
requirements  throughout.  The  definitions  below  describe  the  capabilities  that  the 
SCORM  expects  to  enable: 

•  Accessibility.  The  ability  to  access  instructional  components  from  one  remote 
location  and  deliver  them  to  many  other  locations 

•  Interoperability.  The  ability  to  use  instructional  components  developed  in  one 
location  and  with  one  set  of  tools  or  platform  in  another  location  and  with  a 
different  set  of  tools  or  platform.  (Note:  There  are  multiple  levels  of 
interoperability.) 

•  Durability.  Instructional  components  that  do  not  require  redesign  or  recoding  to 
operate  when  base  technology  changes 

•  Reusability.  The  design  of  instructional  components  so  that  they  can  be 
incorporated  into  multiple  applications. 

These  definitions  can  be  restated  as: 
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•  The  ability  of  a  Web-based  LMS  to  launch  “executable”  content  that  is  authored 
using  tools  from  different  vendors  and  to  exchange  data  with  that  content 

•  The  ability  of  Web-based  LMS  products  from  different  vendors  to  launch  the 
same  executable  content  and  exchange  data  with  that  content  during  execution 

•  The  ability  of  multiple  Web-based  LMS  products/environments  to  access  a 
common  repository  of  executable  content  and  to  launch  such  content. 

During  the  initial  implementation  and  testing  phases,  these  requirement  statements  will 
be  used  as  evaluation  criteria. 

3.4  Web-based  Design  Assumption 

SCORM  assumes  an  Internet,  Web-based  infrastructure  as  a  basis  for  its  technical 
implementation.  This  assumption  was  made  for  several  reasons: 

•  Web/Internet  technologies  and  infrastructure  are  rapidly  expanding  and  provide  a 
mainstream  basis  for  learning  technologies. 

•  Web-based  learning  technologies  standards  do  not  yet  exist. 

•  Web-based  content  can  be  delivered  using  nearly  any  type  of  medium  (e.g.,  CD- 
ROM,  stand-alone  systems,  and/or  as-networked  environments). 

This  approach  embraces  the  mainstream  transition  to  common  content  and  delivery 
formats  that  is  occurring  in  industry.  Computer  operating  system  environments  now 
natively  support  Web  content  formats  such  as  Hypertext  Markup  Language  (HTML)  and 
the  Joint  Photographic  Experts  Group  (JPEG).  The  trend  is  toward  the  use  of  common 
content  formats  that  can  be  used  locally,  on  local  Intranets,  or  over  the  Internet.  The 
SCORM  extends  this  trend  to  learning  technologies. 
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4. 1  Sharable  Courseware  Object  (SCO) 

An  SCO  is  an  interoperable,  durable,  computer-based  course  or  component  of  a  course 
packaged  with  sufficient  information  to  be  reusable  and  accessible. 

4.2  Sharable  Courseware  Object  Reference  Model  (SCORM) 

SCORM  is  a  software  model  that  defines  the  interrelationship  of  course  components,  data 
models,  and  protocols  so  that  courseware  “objects”  are  sharable  across  systems  that 
conform  with  the  same  model. 

4. 3  Course  Structure  Forma  t  ( CSF)  [1  ] 

A  CSF  defines  all  the  course  elements,  the  course  structure,  and  all  external  references 
necessary  to  represent  a  course  and  its  intended  behavior. 

4.3.1  External  Course  Metadata  [la] 

External  course  metadata  is  information  that  can  be  searched  externally,  such  as  the 
course  title,  course  description,  and  version. 

4.3.2  Assignment  Hierarchy  [1b] 

The  assignment  hierarchy  is  a  tree  structure  that  defines  a  hierarchical  lesson  plan  for  a 
course.  The  ordering  of  the  tree  elements  defines  a  default  sequence  for  executing  each 
of  the  assignments  in  the  course. 

4.3.3  Objectives  [1c] 

An  objective  is  a  statement  of  skills,  knowledge,  and  attitudes  to  be  acquired  by  the 
student. 

4.3.4  Assignment  Hierarchy  Metadata  [1  e] 

Assignment  hierarchy  metadata  are  metadata  that  are  described  with  the  specific 
assignments  at  different  levels  within  the  lesson  plan  hierarchy  (e.g.,  course  element 
metadata  within  a  particular  course  hierarchy  that  is  context  specific  to  that  course 
hierarchy). 

4.4  Content  [2] 

This  is  content  that  runs  on  a  client  (i.e.,  executed  within  a  client-side  browser). 
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4.4.1  Content  Metadata  [2a] 

Content  metadata  are  metadata  that  describe  a  [sharable]  “chunk”  of  content.  Content 
metadata  are  not  related  to  a  specific  course  structure  (i.e.,  context-independent 
metadata).  This  is  information  can  be  searched  externally  (e.g.,  content  asset  title, 
description,  and  version). 

4.5  Raw  Media  [3] 

Raw  media  are  media  assets  (e.g.,  images,  sounds,  text,  or  other  presentation  documents) 
that  can  be  incorporated  into  executable  assets  (content)  during  authoring  or  dynamically 
at  runtime.  Media  assets  have  metadata  but  are  not  expected  to  be  used  in  a  standalone 
mode  (i.e.,  outside  of  content). 

4.5.1  Raw  Media  Metadata  [3a] 

Raw  media  metadata  are  metadata  that  describe  raw  media  elements  in  a  noncontext- 
specific  manner.  This  is  information  that  can  be  searched  externally  (e.g.,  media  asset 
title,  description,  date  of  creation,  and  version)  and  that  can  be  used  to  create  a  searchable 
repository  of  sharable  media  elements. 

4.6  Runtime  Environment  [4] 

The  runtime  environment  is  defined  mechanisms  for  starting  (launching)  executable 
content  and  exchanging  data  between  an  LMS  and  the  content. 

4.6.1  Content  Launch  Protocol  [4a] 

Content  launch  protocol  is  the  protocol  used  to  launch  the  executable  content  and  connect 
it  to  the  API  provided  by  an  LMS. 

4.6.2  Content  Application  Program  Interface  (API)  [4b] 

The  content  uses  content  API  to  communicate  with  an  LMS 

4.6.3  Content  Data  Model  [4c] 

The  content  data  model  is  the  definition  of  the  data  exchanged  between  an  LMS  and  the 
content  launched  under  control  of  such  a  system: 

•  The  LMS  makes  student  data  available  to  the  content. 

•  The  content  passes  learner  performance  data  and  other  tracking  information  back 
to  the  LMS . 
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5.  XMLCSF 

5. 1  Overview 

The  purpose  of  the  XML  CSF  is  to  provide  a  means  for  moving  a  course  from  one  LMS 
to  another.  A  CSF  defines  all  the  course  elements,  the  course  structure,  and  all  external 
references  necessary  to  represent  a  course  and  its  intended  behavior. 

This  CSF  is  intended  to  promote  reuse  of  entire  courses  and  encourage  the  reuse  of 
course  components  by  exposing  all  the  details  of  each  course  element.  It  is  intended  to 
reduce  or  eliminate  the  dependency  of  a  course  on  a  particular  LMS  implementation. 

This  CSF  was  co-developed  by  several  organizations,  including  ADL,  AICC,  IEEE,  and 
IMS.  Many  thanks  go  to  Jack  Hyde  and  Bill  McDonald  for  providing  the  basis  of  course 
structure  in  AICC’s  CMI  specifications  (and  supporting  this  effort);  Tyde  Richards,  who 
constructed  the  very  first  XML  versions  of  this  structure;  Thor  Anderson  (IMS)  for  his 
work  in  harmonizing  the  CSF  with  the  IMS  metadata  efforts;  Dan  Rehak  for  keeping  us 
honest;  and  many  others  who  continue  to  contribute  to  this  effort  on  an  ongoing  basis. 

5.2  Scope 

This  CSF  is  (only)  an  intermediate  format  for  representing  Web-based  courses  that  are 
being  moved  from  one  LMS  to  another.  It  does  not  define  LMS  functionality.  It  is 
assumed  that  an  LMS  may  have  a  private,  unique  representation  for  course  elements  and 
structure  and  that  the  LMS  can  “export”  a  CSF  file  or  record  that  can  then  be  “imported” 
by  another  LMS  and  stored  in  its  local  form.  The  CSF  is  not  intended  to  require  LMS 
systems  to  adopt  the  CSF  model  or  structure  internally. 

5.3  Approach 

The  CSF  is  intended  to  represent  a  wide  variety  of  course  structures  and  content 
“aggregations.”  The  CSF  can  represent  content  structures  that  range  from  very  small 
“chunks”  of  content — as  simple  as  a  few  lines  of  HTML  or  short  media  clip — to  highly 
interactive  learning  content  that  is  tracked  by  an  LMS.  The  CSF  is  neutral  about  the 
complexity  of  content,  the  number  of  hierarchical  levels  of  a  particular  course  (i.e., 
“granularity”),  and  the  instructional  methodology  employed  to  design  a  course. 

The  XML  CSF  is  derived  from  the  AICC  content  model  for  course  structure,  properties, 
and  objectives.  This  model  was  chosen  as  a  starting  point  because  key  components  of 
course  representation  are  defined  in  the  AICC’s  Semantic  Document  v3.0  (CMI- 
Sem30.doc).  One  objective  of  this  version  of  the  CSF  is  to  map  the  course  structure, 
properties,  and  objectives  in  the  AICC-defined  tables  into  an  XML  format  for  Web 
applications.  Another  objective  is  to  extend  the  CSF  to  include  additional  features,  such 
as  referencing  external  IMS/IEEE  metadata  records.  Thus,  this  CSF  extends  the  AICC 
CMI  practice  to  include  new  capabilities  for  Web-based  content. 
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5.4  Course  “Packaging” 

The  CSF  should  not  be  confused  with  so  called  “course  packaging.”  Packaging  is  the 
process  of  identifying  all  course  files,  regardless  of  type,  and  then  physically  bundling  all 
these  components  together  with  a  manifest  (packing  slip)  for  movement  from  one 
environment  to  another.  The  CSF  is  simply  one  of  the  “files”  (albeit  a  very  important 
one)  needed  to  move  a  course  physically  from  one  place  to  another.  Actual  content, 
metadata  records,  and  raw  media  must  also  be  “packaged”  with  a  CSF  when  a  course  is 
moved  from  one  place  to  another.  The  CSF  is,  therefore,  a  “blueprint”  for  assembling  all 
of  the  constituent  pieces  once  a  course  has  arrived  at  its  destination. 

5.5  Course  Interchange  Overview 

The  CSF  describes  a  course  using  three  groups  of  information  (see  Figure  5-1).  The  first 
group,  called  globalProperties,  is  the  data  about  the  overall  course.  The  second  group, 
called  block,  defines  the  structure  of  the  course.  The  third  group,  objectives,  defines  a 
separate  structure  for  learning  objectives  with  references  to  course  elements  within  the 
assignment  structure. 


Figure  5-1.  CSF  High-Level  XML  Document  Type  Definition  (DTD)  Structure 
Note  for  Figure  5-1 :  No  notation  =  one  element  required;  “?”=  zero  or  one  (optional). 

5.5.1  Source/Model/Location  Structure 

Several  CSF  elements  use  a  common  substructure  to  define  externally  referenced 
information  or  practices.  The  idea  is  to  provide  a  way  to  determine  which  organizational 
standards,  technical  specifications,  or  other  relevant  information  are  helpful  to 
understanding  the  intent  of  the  course.  Although  the  usage  will  vary  slightly  from  one 
element  to  another,  the  general  intent  is  that  subelement: 

•  Source.  Describes  the  source  or  originator  of  a  given  practice  or  specification  to 
which  this  course  adheres.  Examples  could  include  ADL  CSF,  AICC  CMI,  IEEE 
Learning  Object  Metadata  (LOM),  ARMY  LEARNING  STRUCTURE,  and  so 
forth. 

•  Model.  Describes  a  specific  data  model,  defining  structure,  or  specification  to 
which  this  course  adheres.  Examples  could  include  ADL  SCORM  1.0,  AICC 
CMI  3.0.1,  IEEE  LOM  3.1,  and  so  forth. 
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•  Location.  Describes  where  the  controlling  specification  or  referenced  material 
can  be  found. 

5.5.2  Course  Sequencing  Using  Prerequisites  and  Completion 
Requirements 

The  CSF  elements  block,  au,  and  objective  each  have  subelements  called  prerequisites 
and  completionReq  (completion  requirements).  These  elements  provide  a  field  that  can 
be  used  to  represent  algorithmically  the  sequence  of  events  through  a  course.  These 
elements  mirror  certain  tracked  data  elements  in  the  data  model  described  in  Section  6  of 
this  document.  The  data  model  provides  a  means  for  content  to  report  to  an  LMS  when  a 
particular  part  of  a  course  is  “complete”  or  “incomplete.”  An  LMS  can  then  evaluate  the 
statements  in  prerequisites  and  completionReq  to  determine  what  the  student  should  be 
delivered  next. 

The  prerequisites  element  defines  what  other  parts  of  the  course  must  be  completed 
before  starting  the  parent  block,  au,  or  objective.  Similarly,  completionReq  defines  what 
other  course  parts  must  be  completed  to  consider  the  parent  “done.”  This  allows  an  LMS 
to  compute  multiple  paths  through  a  course. 

The  AICC’s  Semantic  Document  v3.0  (CMI-Sem30.doc)  (Section  6)  describes  in  great 
detail  the  use  of  prerequisites  and  completion  requirements.  Table  5-1,  which  is 
extracted  from  the  AICC  document,  describes  the  logic  encoding  used  for  these  two 
elements. 


Table  5-1 .  Logic  Encoding  Used  for  the  prerequisites  and  completionReq  Elements 


And 

All  elements  separated  by  an  &  must  be  compete  for  the  expression  to  be  evaluated  as  complete. 

A34  &  A36  &  A38 

Assignable  units  numbers  34,  36,  and  38  must  all  be  complete  (Passed  or  Completed)  for  the  group  to 
be  considered  complete. 

Or 

If  any  of  the  elements  separated  by  an  are  passed,  the  expression  is  considered  true. 

A34=P  |  A36=P  |  A38=P 

Ifany  one  of  the  lessons,  34,  36,  or  38,  are  passed,  the  group  is  considered  complete. 

Not 

An  operator  that  returns  incomplete  (false)  if  the  following  element  or  expression  is  complete,  and 
returns  complete  (true)  if  the  following  element  or  expression  is  incomplete  (false). 

Element  Identifier:  A34 

Requirement:  ~A35 

The  student  may  enter  unit  A34  as  long  as  unit  A35  has  not  been  completed  (that  is,  the  status  of 

A35  must  be  Incomplete,  Failed,  or  Not  attempted).  If  assignable  unit  A35  is  complete,  the  student 
may  not  enter  unit  A34. 

Equals 

An  operator  that  returns  true  when  representations  on  both  sides  of  the  symbol  have  the  same 
values. 

Element  Identifier:  A34 

Requirement:  A33=Passed 

The  student  may  enter  unit  A34  if  he  or  she  has  passed  unit  A33. 
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Table  5-1 .  Logic  Encoding  Used  for  the  prerequisites  and 
compietionReq  Elements  (Continued) 


Not 

equals 

An  operator  that  returns  true  when  elements  on  both  sides  of  the  symbol  have  different  values. 

Element  Identifier:  A34 

Requirement:  A35<>Passed 

The  student  may  enter  unit  A34  as  long  as  he  or  she  has  not  passed  A35.  Notice  the  difference 
between  this  expression  and  the  example  for  the  not  operator.  The  equivalent  of  ~A35  is 
(A35oPassed  &  A35<>C ompleted) 

Set 

A  list  of  course  elements  separated  by  commas  and  surrounded  by  curly  brackets  -  {  }.  A  set  differs 
from  a  block,  in  that  the  set  is  defined  only  for  purposes  of  the  prerequisite  file.  A  set  has  no  effect  on 
the  structure  of  the  course. 

{A34,  A36,  A37,  A39} 

Assignable  units  A34,  A36,  A37,  and  A39  are  part  of  a  set. 

Separator 

The  comma  is  used  to  separate  the  members  of  a  set.  Each  member  of  the  set  can  be  evaluated 
as  a  Boolean  element-  complete  or  incomplete. 

{A34,  A36,  A37,  A39} 

Assignable  units  A34,  A36,  A37,  and  A39  are  each  separated  by  a  comma  in  this  set. 

X* 

X  is  an  integer  number.  This  operator  means  thatX  or  more  members  of  the  set  that  follows 
must  be  complete  for  the  expression  to  be  complete  (true). 

Element  Identifier:  A38 

Requirement:  3*{A34,  A36,  A37,  A39} 

Any  three  or  more  of  the  following  units  -  34,  36,  37,  39  -  must  be  complete  before  the  student 
can  enter  unit  38. 

Evaluate 

1st 

The  expression  within  the  parenthesis  (  )  must  be  evaluated  before  combining  its  results  with 
other  parts  of  the  logical  statement.  Parentheses  may  be  nested.4 

Element  Identifier:  A39 

Requirement:  A34  &  A35  |  A36 

In  this  statement,  completing  A36  all  by  itself  enables  the  student  to  enter  A39. 

Element  Identifier:  A39 

Requirement:  A34  &  (A35  |  A36) 

Adding  the  parenthesis  makes  it  necessary  to  complete  at  least  two  units  (A36  all  by  itself  is  no 
longer  sufficient)  to  enter  unit  A39. 

The  prerequisites  and  compietionReq  elements  require  that  their  values  be  of  XML  type 
CD  AT  A  to  preserve  all  of  the  characters  within  a  sequencing  expression.  A  “type” 
attribute  is  also  provided  to  identify  the  type  of  algorithmic  script  being  used  in  the 
CD  AT  A  field.  In  the  following  example,  the  aicc_script  “language”  defined  above  is  in 
use,  and  blocks  Bl,  B2,  and  assignable  unit  A1  must  be  completed  before  the  parent  may 
be  entered: 

prerequisites  type="aicc_script">  <! [CDATA[B1&B2&A1] ] > 
</prerequisites> 


5.5.3  Unique  IDs  and  ID  References,  and  Aliases 

Three  of  the  CSF  elements — block,  au,  and  objective — use  the  XML  “ID”  and  “IDRef  ’ 
attributes  to  identify  uniquely  other  elements  within  the  CSF.  These  three  elements  are 
candidate  targets  for  reference  elsewhere  within  the  CSF. 


4Operator  precedence  is  the  same  as  in  the  C  programming  language,  including  the  use  of  parenthesis. 
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XML  requires  that  these  attribute  values  begin  with  a  letter  and  may  otherwise  be 
composed  of  letters,  digits,  hyphens,  underscores,  and  full-stop  characters.  XML  also 
requires  the  attribute  value  to  be  unique  to  the  XML  document  (which  fits  the  usage  in 
this  course  representation).  ID  attributes  may  not  have  fixed  default  values,  and  only  one 
attribute  per  element  may  be  of  type  ID.  It  is  assumed  that  the  assignment  of  ID  values 
will  be  automated  within  tools  and  LMS  environments  to  ensure  uniqueness. 

SCORM  has  adopted  the  following  usage  convention: 


Block 

B +int 

Assignable  Unit  (AU) 

k+int 

Objective 

0+int 

Note:  This  convention  closely  follows  prior  AICC  practices  except  that  “O”  is  used  for 
Objective  instead  of  “J”  for  “Objective”  IDs.  This  change  was  made  for  clarity. 

ID  References  (IDREF)  are  essentially  “pointers”  to  specific  CSF  elements  that  have  IDs 
and  must  match  one  of  the  IDs  in  the  CSF  record. 

Note:  Provision  has  been  made  for  a  “relation”  attribute  for  ID  References.  This  is  in 
recognition  of  the  need  to  define  the  nature  of  a  reference  for  proper  interpretation  by  an 
LMS.  An  objective,  for  example,  might  have  a  relation  that  is  “satisfied  by  ”  the 
completion  of  a  block  reference.  Because  no  relations  models  have  been  defined  at  this 
time,  however,  this  attribute  is  reserved  for  future  use. 

Similar  to  IDs,  there  are  three  “aliases”  in  the  content  hierarchy:  blockAlias,  AuAlias, 
and  Objective  Alias.  These  were  provided  as  a  shorthand  way  to  provide  a  second  or  third 
(or  more)  reference  to  the  same  course  element  without  having  to  restate  the  same 
information  in-line.  Similar  to  ID  References,  an  alias  must  match  an  ID  within  the  same 
XMF  record.  By  convention,  it  is  expected  that  aliases  will  not  be  used  in  a  CSF  record 
until  after  the  referenced  element  has  been  defined  (to  avoid  the  need  for  forward 
referencing). 

5.5.4  Identification  Model 
Title  and  Description 

The  same  Identification  subtree  structure  is  used  under  blocks ,  aus,  and  objectives.  The 
most  important  elements  of  this  model  are  title  and  description.  Note  that  the 
identification-title  is  a  minimum  required  element  throughout  the  CSF.  The  description 
is  optional. 

At  first  glance,  title  and  description  look  similar  to  the  same  kind  of  metadata  discussed 
in  Section  7  of  this  document.  This  is  not  exactly  the  case,  although  the  contents  of  these 
elements  could  contain  the  same  or  similar  information  to  that  found  in  a  stand-alone 
metadata  record.  Within  the  CSF,  these  elements  are  meant  to  store  the  title  and 
description  within  the  context  of  the  course.  A  reusable  learning  object,  for  example, 
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might  have  a  generic  name  in  a  separate  XML  record  used  principally  to  identify  it. 
Within  a  course,  however,  the  course  designer  may  want  to  rename  that  object  to 
something  more  meaningful  in  the  context  of  a  particular  course. 

Similarly,  a  description  for  a  reusable  content  object  might  describe  what  the  object  does 
(e.g.,  “Provides  an  introduction  to  XML  for  novices”).  Within  the  CSF,  however,  the 
description  might  describe  what  the  object  is  within  a  specific  course  (e.g.,  “Chapter  3 — 
First  Introduction  to  XML  Structures”). 

Developer  and  Curricular  Labels 

Identification  also  provides  a  labels  element  that  can  be  used  to  store  information  that 
might  be  useful  to  course  developers.  Developer  may  be  used  to  store  a  tag  or  label 
useful  to  the  developer  that  might  be  in  use  by  convention  within  an  organization  or  as  a 
by-product  to  the  use  of  a  tool.  These  elements  allow  such  information  to  be 
contextualized  and  carried  along  with  course  when  it  is  moved. 

The  curricular  label  is  also  “informative”  and  is  intended  to  describe  the  name  (label)  of 
the  element  according  to  local  practices.  This  label  could  be  used  to  identify  names  such 
as  “Course,”  “Unit,”  “Lesson,”  “Module,”  “Learning  Step,”  and  so  forth.  These  terms 
are  expected  to  be  derived  from  a  known  model  using  a  known  vocabulary  that  should  be 
defined  under  globalProperties  using  the  curricularTaxonomy  element. 

The  labels  subtree  is  intended  to  capture  valuable  and  important  information  about  a 
course  and  its  construction;  however,  these  elements  are  considered  “informative”  and 
are  not  expected  to  affect  how  content  is  actually  delivered. 

5.5.5  CSF  Extension  Mechanism 

Throughout  the  CSF,  provisions  have  been  made  for  extensions.  The  extension  element 
includes  information  about  the  source  of  the  extension,  its  model,  the  location  for  the 
defining  specification,  and  name/value  pairs  of  extended  elements. 

This  extension  mechanism  was  included  with  the  realization  that  no  course  structure 
model  could  completely  anticipate  the  needs  of  all  users;  however,  the  use  of  extensions 
comes  with  great  risk.  Extensions  unilaterally  implemented  by  one  LMS  could  be,  at 
best,  meaningless  to  another  LMS  and,  at  worst,  result  in  the  course  not  behaving  as 
intended  or  perhaps  not  operating  at  all  when  moved. 

Therefore,  it  is  recommended  that  extensions  be  implemented  with  care  and  that 
appropriate  documentation  and  organizational  policy  be  established  to  manage 
community- specific  additions. 

It  is  also  expected  that  conventions  for  extensions  and  provisions  for  name  spaces 
associated  with  subcommunities  will  evolve  to  ease  the  risk  of  local  customization. 
Future  versions  of  this  document  are  expected  to  provide  guidance  in  this  area. 
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5.6  Course  Information — globalProperties 

The  globalProperties  node  of  the  CSF  contains  or  references  information  about  the 
course  as  a  whole.  It  also  provides  information  describing  the  general  approach  used 
during  the  design  of  the  course.  See  Figure  5-2. 


Figure  5-2.  globalProperties  XML  DTD  Structure 

Note  for  Figure  5-2:  No  notation  =  one  element  required;”?”  =  zero  or  one  (optional);  “+”=  one 
or  more  required;  “*”  =  zero  or  more  required. 

5.6.1  Global  Properties — externalMetadata 

External  course  metadata  are  referenced  within  globalProperties  in  metadataExternalRef 
These  metadata  define,  among  other  things,  information  that  can  be  searched  externally, 
such  as  the  course  title,  course  description,  version,  and  so  forth.  The  SCORM  assumes 
that  the  external  course  metadata  “pointed  to”  (referenced)  by  metadataExternalRef  is  a 
separate  metadata  record,  as  defined  in  Section  7.2  of  this  document. 

The  CSF  “points  to”  an  external  metadata  record  rather  than  including  it  in-line  to  avoid 
redundancy  and  to  reduce  the  CSF’s  overall  size  and  complexity.  Because  a  stand-alone 
metadata  definition  based  on  the  IEEE  LOM  specification  exists,  it  does  not  have  to  be 
duplicated  within  the  CSF. 

5.6.2  Global  Properties — curricularTaxonomy 

globalProperties  provides  a  tag  for  how  courses  are  constructed,  called 
curricularTaxonomy.  This  tag  can  identify  the  methodology  of  a  particular  community 
of  users  in  assembling  course  components.  This  element  indicates  the  user  community 
and,  therefore,  infers  the  structure  of  the  course,  naming  conventions  (e.g.,  unit,  lesson, 
learning  step,  and  so  forth),  and  number  of  levels  or  tiers  of  content  aggregation. 
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Appendix  E  of  this  document  gives  some  examples  of  different  course  structures. 
Table  5-2  illustrates  how  curricularTaxonomy  might  be  used: 


Table  5-2.  Using  the  curricularTaxonomy 


Course 

Course 

Course 

Course 

Module 

Block 

Phase 

Performance 

Objective 

Lesson 

Module 

SubCourse 

(Annex) 

Enabling 

Objective 

Learning 

Objective 

Lesson 

Lesson 

Teaching  Point 

Learning 

Steps 

Learning 

Objective 

Task 

Learning 

Objective 

Learning  Step 

In  these  examples,  the  curricularTaxonomy  model  element  helps  to  predict  the  probable 
depth  of  the  content  hierarchy.  For  example,  the  Marine  model  contains  seven  course 
levels,  the  Army  and  Air  Force  models  contain  five  course  levels,  and  the  Canadian 
model  contains  four  levels. 

Understanding  the  design  methodology  used  during  course  construction  and  the  different 
approaches  to  content  aggregation  will  assist  in  content  reuse  and  provide  important 
information  to  an  FMS  when  courses  are  moved. 

5.6.3  Global  Properties — extensions 

See  Section  5.5.5,  CSF  Extension  Mechanism. 

5.7  Course  Structure  Hierarchy— block 

The  block  group  defines  all  the  course  elements  and  their  organizational  structure.  This 
tree  structure  defines  a  hierarchical  lesson  plan  for  a  course.  The  ordering  of  the  tree 
elements  defines  a  default  sequence  for  the  execution  of  each  of  the  “assignments”  in  the 
course.  Embedded  within  this  tree  structure  are  data  elements  defining  the  type,  source, 
and  location  of  each  course  element.  Figure  5-3  shows  a  sample  course  structure. 

Figure  5-4  shows  the  block  XMF  DTD  structure. 
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Figure  5-3.  Example  Course  Structure 

The  block  structure  defines  two  types  of  course  content:  blocks  and  assignable  units 
(aus).  The  terms  block  and  au  are  drawn  directly  from  the  AICC’s  CMI  specification 
AICC’s  Document  CMI001,  AICC  CMI  Guidelines  for  Interoperability  (Revision  3.0.1, 
24  November  1999). 

A  block  is  a  hierarchical  grouping  of  other  blocks  or  assignable  units.  The  top-most 
block  (the  root  of  the  hierarchical  tree)  is  the  top  level  of  the  “course.”  This  top  level 
may  contain  blocks  or  assignable  units,  or  both. 

Blocks  may  be  nested.  Blocks  might  group  together  smaller  groups  of  blocks,  which,  in 
turn,  may  contain  references  to  content  (aus).  Examples  of  blocks  might  include 
“chapters,”  “units,”  “learning  steps”,  and  so  forth. 

This  hierarchical  approach  to  representing  course  structure  in  the  CSF  is  intended  to 
accommodate  a  wide  variety  of  courseware  models.  Simple  courses  may  not  have  many 
levels  of  blocks,  while  complex  courses  could  have  many  blocks  within  blocks.  The 
globalProperties  tag,  curricularTaxonomy,  is  intended  to  identify  the  model  convention 
type. 
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Figure  5-4.  block  XML  DTD  Structure 

Note  for  Figure  5-4:  No  notation  =  one  element  required;  “?”  =  zero  or  one  (optional);  “+”  =  one 
or  more  required;  “*”  =  zero  or  more  required. 

5.7.1  Block — externalMetadata 

The  optional  externalMetadata  subelement  offers  course  developers  the  opportunity  to 
more  fully  describe  course  blocks  throughout  the  content  hierarchy.  Similar  to 
globalProperties ,  this  element  is  expected  to  point  to  stand-alone  XML  metadata  records 
as  specified  in  Section  7  of  this  document. 

5.7.2  Block — objectivesRef 

This  subelement  is  used  to  “point”  to  an  objective.  It  ties  a  particular  portion  of  a  course 
to  a  specific  objective.  See  Section  5.5.3,  Unique  IDs  and  ID  References,  and  Aliases. 

5.7.3  Block — identification 

This  sublement  provides  context- specific  information  about  a  block  including  title, 
description,  curricular  label,  and  developer  label.  See  Section  5.5.4,  Identification  Model. 
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5.7.4  Block — prerequisites 

This  subelement  defines  what  portions  of  a  course  must  be  completed  before  this 
element’s  parent  may  be  started.  See  Section  5.5.2,  Course  Sequencing  Using 
Prerequisites  and  Completion  Requirements. 

5.7.5  Block — completionReq 

This  subelement  defines  what  portions  of  a  course  must  be  completed  before  this 
element’s  parent  is  considered  to  be  “complete.”  See  Section  5.5.2,  Course  Sequencing 
Using  Prerequisites  and  Completion  Requirements. 

5.7.6  Block — extensions 

See  Section  5.5.5,  CSF  Extension  Mechanism. 

5.7.7  Block — au/biock 

This  subelement  can  include  one  or  more  subblocks  and/or  one  or  more  assignable  units. 
This  defines  the  course  hierarchy.  The  following  XML  fragment  illustrates  the 
hierarchical  tree  structure: 


<course> 

<block  id="Bl"> 

<identif ication> 

<t it le>Marit ime  Navigat ion</t it le> 

<labels> 

<curricular>UNIT</ curricular> 

</labels> 

</identif ication> 

<block  id="B2"> 

<identif ication> 

<title>Inland  Rules  of  the  Road</title> 
<labels> 

<curricular>MODULE</curricular> 

</labels> 

</identif ication> 

<au  id="Al"> 

<identif ication> 

<title>Ref erences</title> 

</identif ication> 

<launch> 

<location>/Courses/Course01/Lesson01/au01 . html</location> 
</launch> 

</au> 

<block  id="B3"> 

<identif ication> 

<title>Steering  &# 38;  Sailing  Rules</title> 
<labels> 

<curricular>MODULE</curricular> 

</labels> 

</identif ication> 
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5.7.8  Block — blockAlias 

This  subelement  provides  a  reference  to  a  previously  defined  block  to  avoid  the  need  to 
duplicate  identical  block  definitions  within  a  block  structure.  See  Section  5.5.3,  Unique 
IDs  and  ID  References,  and  Aliases. 

5.8  Assignable  Unit — au 

References  to  course  content  in  the  CSF  are  made  using  the  au  (assignable  unit)  element. 
This  element  references  learning  content  that  is  to  be  launched  by  an  LMS  on  the 
student’s  client  platform.  The  au  element  within  the  CSF  contains  all  the  context- specific 
information  needed  to  launch  a  “chunk”  of  content,  such  as  its  location,  name,  launch 
parameters,  and  prerequisites.  [Note:  The  au  elements  may  be  arbitrarily  small  pieces  of 
content  that,  at  a  minimum,  are  launched  and  then  terminated  with  no  communications 
with  an  LMS,  or  they  may  be  more  complex  pieces  of  content  that  generate  data  that  are 
tracked  by  an  LMS.]  Figure  5-5  shows  the  au  XML  DTD  structure. 

The  au  element  in  the  CSF  may  optionally  use  externalMetatdata  to  reference  an  external 
metadata  record  that  could  contain  information  about  a  piece  of  content  that  is 
independent  of  a  particular  course  (i.e.,  noncontext  specific).  Such  metadata  would  be 
useful  within  “content  repositories.” 

5.8.1  Assignable  Unit — externalMetadata 

The  optional  externalMetadata  subelement  is  intended  to  point  to  external  stand-alone 
XML  records  that  more  fully  describe  the  assignable  unit  content  referenced  in  this 
parent’s  element.  This  reference  is  expected  to  be  informational  rather  than  functional. 

5.8.2  Assignable  Unit — objectivesRef 

This  subelement  is  used  to  “point”  to  an  objective.  It  ties  a  particular  portion  of  a  course 
to  a  specific  objective.  See  Section  5.5.3,  Unique  IDs  and  ID  References,  and  Aliases. 

5.8.3  Assignable  Unit — identification 

This  subelement  provides  context-specific  information  about  an  assignable  unit  including 
title,  description,  curricular  label,  and  developer  label.  See  Section  5.5.4,  Identification 
Model. 

5.8.4  Assignable  Unit — prerequisites 

This  subelement  defines  what  portions  of  a  course  must  be  completed  before  this 
element’s  parent  can  be  started.  See  Section  5.5.2,  Course  Sequencing  Using 
Prerequisites  and  Completion  Requirements. 
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Figure  5-5.  au  XML  DTD  Structure 

Note  for  Figure  5-5:  No  notation  =  one  element  required;  “?”  =  zero  or  one  (optional);  “+”  =  one 
or  more  required;  “*"  =  zero  or  more  required. 

5.8.5  Assignable  Unit — completionReq 

This  subelement  defines  what  portions  of  a  course  must  be  completed  before  this 
element’s  parent  is  considered  to  be  “complete.”  See  Section  5.5.2,  Course  Sequencing 
Using  Prerequisites  and  Completion  Requirements. 
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5.8.6  Assignable  Unit — timeLimit 


This  subelement  has  two  time-related  subelements:  maxTime Allowed  and 
timeLimit  Action.  The  first  subelement,  maxTimeAllowed,  defines  the  amount  of  time  the 
student  is  allowed  to  have  in  the  current  attempt  on  the  lesson.  The  second  subelement, 
timeLimitAction,  defines  what  a  lesson  should  do  when  the  maximum  time  allowed  has 
elapsed.  Similar  to  prerequisites  and  completionReq,  this  element  has  a  “type”  attribute 
for  identifying  the  kind  of  value  in  use.  The  “AICC”  case,  which  the  SCORM  has 
adopted,  has  a  fixed  vocabulary  for  this  element: 


Time  Limit  Action: 


Exit 

Continue 

Message 

no  message 

5.8.7  Assignable  Unit — launch 

This  subelement  has  three  subelements:  location,  parameter  String,  and  dataFromLMS . 

The  location  subelement  contains  the  Universal  Resource  Identifier  (URI)  of  the  actual 
assignable  unit  content  to  be  launched.  This  is  the  manner  in  which  the  CSF  “points”  to 
launchable  assignable  units. 

The  optional  parameterString  subelement  holds  a  character  string  to  use  during  content 
launch  if  needed.  [This  is  similar  to  options  one  might  type  following  the  name  of  a 
program  or,  in  Java,  the  arguments  one  would  process  in  main  (String[]  args)]. 

The  dataFromLMS  subelement  provides  a  place  for  initialization  data  expected  by  the 
content  during  launch.  These  data  are  unconstrained  and  undefined.  Note:  This  element 
is  not  yet  well  defined  and  should  be  used  with  caution. 

5.8.8  Assignable  Unit — masteryScore 

This  subelement  establishes  the  passing  score  for  the  assignable  unit  in  this  case.  What  is 
considered  a  passing  score  often  depends  on  the  context  of  an  assignable  unit  within  a 
course.  Some  courses  may  set  the  mastery  score  for  an  “au”  higher  than  in  other  courses. 

This  subelement  assumes  that  the  assignable  unit  has  some  content  that  will  report  a  score 
(e.g.,  a  test)  over  the  API  and  data  model  defined  in  Section  6  of  this  document. 

5.8.9  Assignable  Unit — extensions 

See  Section  5.5.5,  CSF  Extension  Mechanism. 

5.8.10  Assignable  Unit — auAlias 

This  subelement  provides  a  reference  to  a  previously  defined  assignable  unit  to  avoid  the 
need  to  reduplicate  identical  au  definitions  within  a  block  structure.  See  Section  5.5.3, 
Unique  IDs  and  ID  References,  and  Aliases. 
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5.9  Objectives 

At  the  highest  level,  course  objectives  are  statements  of  skills,  knowledge,  and  attitudes 
to  be  acquired  by  the  student.  Within  the  CSF,  the  objectives  group  provides  the  means 
for  identifying  objective  titles,  descriptions,  prerequisites,  completion  requirements,  and 
so  forth.  Figure  5-6  shows  the  objectives  XML  DTD  structure. 


Figure  5-6.  objectives  XML  DTD  Structure 

Note  for  Figure  5-6:  No  notation  =  one  element  required;  “?”=  zero  or  one  (optional);  “+”  =  one 
or  more  required;  “*”  =  zero  or  more  required. 

These  statements  of  objectives  may  be  hierarchically  nested  (or  simply  listed)  and  may 
include  explicit  references  to  specific  course  elements  within  the  assignments  hierarchy. 
This  permits  an  LMS  to  track  the  completion  status  of  objectives  and,  thus,  provides  a 
means  for  the  LMS  to  determine  appropriate  paths  through  course  content. 

Note:  The  root  of  the  objective  structure  is  the  objectives  ( plural )  element  and  is  not  in 
itself  an  objective  (singular).  All  actual  objective  elements  occur  somewhere  under  the 
objectives  root.  The  reason  for  this  construct  is  that  objectives  may  be  a  single,  “flat” 
list  of  objectives,  a  hierarchy  of  objectives,  or  both.  The  top-level  objectives  element 
provides  a  specific  place  to  “hang”  objective  elements,  regardless  of  the  underlying 
structure. 

5.9.1  Objective — externalMetadata 

This  optional  externalMetadata  subelement  offers  course  developers  the  opportunity  to 
more  fully  describe  objectives  blocks  throughout  the  objectives  hierarchy.  At  this  time, 
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no  defined  current  practice  for  applying  metadata  to  objectives  exists;  therefore,  this 
category  exists  mainly  for  consistency  with  the  rest  of  the  CSF  model,  with  the 
expectation  that  it  will  provide  a  potential,  future  value  yet  to  be  defined. 

5.9.2  Objective — assignmentRef 

This  subelement  is  used  to  “point”  to  a  particular  block  or  assignable  unit  in  the  content 
hierarchy.  The  term  “assignment”  is  used  to  refer  to  either  a  block  or  an  assignable  unit. 
It  ties  a  particular  objective  to  a  specific  part  of  a  course.  See  Section  5.5.3,  Unique  IDs 
and  ID  References,  and  Aliases. 

5.9.3  Objective — identification 

This  subelement  provides  context-specific  information  about  a  block,  including  title, 
description,  curricular  label,  and  developer  label.  See  Section  5.5.4,  Identification  Model. 

5.9.4  Objective — prerequisites 

This  subelement  defines  what  portions  of  a  course  must  be  completed  before  this 
element’s  parent  can  be  started.  See  Section  5.5.2,  Course  Sequencing  Using 
Prerequisites  and  Completion  Requirements. 

5.9.5  Objective — completionReq 

This  subelement  defines  what  portions  of  a  course  must  be  completed  before  this 
element’s  parent  is  considered  to  be  “complete.”  See  Section  5.5.2,  Course  Sequencing 
Using  Prerequisites  and  Completion  Requirements. 

5.9.6  Objective — extensions 

See  Section  5.5.5,  CSF  Extension  Mechanism. 

5.9.7  Objective — objectiveAlias 

This  subelement  provides  a  reference  to  a  previously  defined  objective  to  avoid  the  need 
to  duplicate  identical  objective  definitions  within  an  objectives  structure.  See  Section 
5.5.3,  Unique  IDs  and  ID  References,  and  Aliases. 

5.10  CSF  Element  Definitions/Descriptions 

Table  5-3  lists  the  CSF  element  definitions  and  descriptions. 
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Table  5-3.  CSF  Element  Definitions/Descriptions 


assignmentRef 

Reference  to  a  particular  element  in  the  assignment 
hierarchy  (e.g.,  <assignmentRef  relation="satisfied 
by  "ta  rg  e  tl  D  s  ="B  1 ,  A  2  3  "/>) . 

Relation  = 

(reserved) 

TargetIDs:  List  of 
Identifier  Refs 

au 

au  is  the  smallest  element  of  instruction  or  testing  to  which  a 
student  can  be  routed  by  a  LMS.  It  refers  to  "content" 
launched  by  the  LMS  system.  This  holds  a  unique  (to  this 
course)  ID  identifier  for  a  particular  au.  IDs  are  generated 
by  the  application  (e.g.,  an  LMS)  thatcreates  a  CSF  XML 
file.  (Other  elements  may  refer  to  this  unique  ID.) 

Id  =  Identifier  Value; 
must  start  with  "A" 

auAlias 

Reference  to  a  previously  defined  au  (permits  one 
assignable  unit  to  be  used  more  than  once  within  a  course). 

Targeted  =  Identifier 
Value 

block 

A  grouping  of  related  structural  elements.  Blocks  contain 
either  assignable  units  or  other  blocks  or  both.  Blocks 
always  contain  other  course  elements.  This  holds  a  unique 
(to  this  course)  ID  identifier  for  a  particular  block.  IDs  are 
generated  by  the  application  (e.g.,  an  LMS)  thatcreates  a 

CSF  XML  file.  (Other  elements  may  refer  to  this  unique  ID.) 

Id  =  Identifier  Value; 
Default  = 

REQUIRED 

blockAlias 

Reference  to  a  previously  defined  block  (permits  one  block 
to  be  used  more  than  once  within  a  course). 

Targeted  =  Identifier 
Value 

completionReq 

Course  elements  that  a  student  must  complete  before 
considering  a  given  structure  element  complete.  It  uses  a 
"script"  that  defines  the  logical  rules  to  be  applied.  The 
script  type  must  be  defined  (e.g.,  completion 
type="aicc  script"> <![C DATA[B1&B2&A1]]> <completion>). 

Type  =  Character 
Data; 

Value  =CDATA 

course 

Root  level  of  Course  Structure  representation. 

curricular 

Local  name  of  course  element  (e.g.,  "UNIT",  "MODULE," 
"LEARNING  STEP"). 

PCDATA 

curricularTaxonomy 

Organizational  methodology  used  to  construct  the  course 

PCDATA 

dataFromLMS 

Unconstrained  (undefined)  initialization  data  expected  by 
content  when  it  is  launched  by  the  LMS. 

PCDATA 

description 

Context-specific  textual  information  about  the  course 
element.  It  can  contain  the  purpose,  scope,  or  summary. 
(Defined  by  course  author). 

PCDATA 

developer 

Developer  label:  an  organization-specific  identifier  (e.g., 
D509). 

PCDATA 

extensions 

Defines  extensions  to  course  element  definitions  and  their 
source. 

external  Metadata 

The  value  of  this  element  refers  or  points  to  the  location  of 
the  metadata  describing  this  course. 

globalProperties 

Properties  of  the  course  as  whole. 

identification 

Identifies  course  context-specific  information. 

labels 

Context-specific  local  label  (e.g.,  unit,  chapter,  learning 
step). 

launch 

Information  needed  by  an  LMS  to  launch  an  assignable  unit. 

location 

Universal  Resource  Locator  (URL)  Location. 

PCDATA 

masteryScore 

Tells  LMS  how  to  compute  the  score  returned  by  LMS  and 
defines  the  passing  score  for  this  assignable  unit  in  this 
context. 

PCDATA 

MaxTimeAllowed 

***  maxTimeAllowed:  The  amount  of  time  the  student  is 
allowed  to  have  in  the  current  attempt  on  the  lesson 

PCDATA 

(FormatTBD) 
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Table  5-3.  CSF  Element  Definitions/Descriptions  (Continued) 


model 

Name  of  a  specific  data  model  used  by  this  course  (e.g., 

"cmi”,  or  "ARMY314",  or  "IMS  vl.O"). 

PCDATA 

name 

Descriptive  name  of  a  course  property  extension  (e.g., 
"difficulty, "as  in  degree  of) . 

PCDATA 

objective 

A  statement  of  skills,  knowledge,  and  aptitudes  to  be 
acquired  by  the  student.  This  holds  a  unique  (to  this  course) 

ID  identifier  for  a  particular  objective.  IDs  are  generated  by 
the  application  (e.g.,  an  LMS)  thatcreates  a  CSF  XML  file 
(other  elements  may  refer  to  this  unique  ID). 

id  =  Identifier  Value; 
Must  start  with  "0" 

objectiveAlias 

Reference  to  a  previously  defined  objective  (permits  one 
objective  to  be  used  more  than  once  within  a  course). 

targetID  =  Identifier 
Ref 

objectiveRef 

Reference  to  a  particular  objective  in  the  objective  hierarchy. 

relation  =  (reserved) 
targetIDs  =  List  of 
Identifier  Refs 

objectives 

Root  level  of  objectives  tree.  Statements  of  skills, 
knowledqe,  and  aptitudes  to  be  acquired  by  the  student 

parameterstring 

String  of  characters  needed  to  successfully  launch  a  content 
assignable  unit. 

PCDATA 

prerequisites 

Expression  indicating  what  a  student  must  accomplish 
before  beginning  this  course  element.  Course  elements  that 
a  student  must  complete  before  beginning  a  block  or 
assignable  unit.  It  uses  a  "script"  that  defines  the  logical 
rules  to  be  applied.  The  script  type  must  be  defined,  e.g., 

<p  re  requisites  type="aicc_script"><![CDATA[Bl&B2&Al]]> 
</prerequisites>. 

type  =  Character 
Data;; 

valued  DATA 

property 

Name/value  pair  extension  for  this  course. 

source 

Authority  or  source  of  data  model  w/reference  to  a  spec.  If 
available  e.g.,  "AICC  AGROIO  v3.4",  or  ARMY  TRADOC 
specl23,  or  "IMS BP  v4.2" 

PCDATA 

timeLimit 

Time  values  or  actions  associated  with  this  assignable  unit 
in  this  context. 

timeUmitAction 

What  the  lesson  is  to  do  when  the  max  time  allowed  is 
exceeded.  AICC  examples:  "exit, ""continue, ""message." 

type  =  Character 

Data; 

value  =PCDATA 

title 

Context  specific  title.  Can  be  used  by  an  LMS  system  in 
menus,  screens,  and  so  forth. 

PCDATA 

value 

Value  associated  with  the  named  extension  (e.g.,  "easy"). 

PCDATA 

5.11  Examples 

The  following  examples  are  intended  to  illustrate  CSF  concepts  and,  for  clarity,  include  a 
much  smaller  number  of  elements  than  would  exist  in  a  true  CSF  record. 

5.1 1 .1  Simplest  Example  of  CSF  Record 

<?xml  version=“  1 .0”  encoding=“UTF-8”?> 
clDOCTYPE  course  SYSTEM  “file:scormcsf(1.0).dtd”  > 

<course> 

cl—***  This  is  the  smallest  possible  valid  CSF  record. 

It  has  only  one  assignable  unit  (au)  and  lists  only  a  title— > 

<block> 

<au  id='*Al”> 
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<identification> 

<title>A  Really,  Really  Small  Course  Chunk  Pointing  to  Nothing</title> 

</identification> 

</au> 

</block> 

</course> 

5.11.2  Simple  Example  Pointing  To  Content 

<?xml  version=“1.0”  encoding=“UTF-8”?> 

<!DOCTYPE  course  SYSTEM  “file:scormcsf(1.0).dtd  “  > 

<course> 

<!—***  To  the  small  CSF  record  example  here  is  added  reference  to  external  content— > 

<block> 

<au  id=“Al”> 

<identification> 

<title>A  Really,  Really  Small  Course  Chunk  Pointing  to  Something</title> 

</identification> 

<launch> 

<location>http://www. notmuch.com/smallchunk.html  </location> 

</launch> 

</au> 

</block> 

</course> 

5.11.3  Example  of  Course  With  One  Block 

<?xml  version=“  1 .0”  encoding=“UTF-8”?> 

<!DOCTYPE  course  SYSTEM  “file:scormcsf(1.0).dtd  > 

<course> 

<!—***  This  is  an  example  of  a  course  with  one  block 
containing  two  assignable  [nee  atomic]  content  units.— > 

<block> 

<block  id=“Bl”> 

<identification> 

<title>Introduction  to  Blocks  101  <c/title> 

<description>This  is  a  simple  block  of  course  elements;  not  much  to  build  with  yet.</description> 
</identification> 

<au  id=“Al”> 

<identification> 

<title>Building  With  Atoms</title> 

</identification> 

</au> 

<au  id=“A2”> 

<identification> 

<title>Splitting  Atoms  With  Hairs</title> 

</identification> 

</au> 

</block> 

</block> 

</course> 

5.11.4  Example  of  Course  With  Blocks  Within  Blocks 

<?xml  version=“1.0”  encoding=“UTF-8”?> 

<!DOCTYPE  course  SYSTEM  “file:scormcsf(1.0).dtd  “  > 

<course> 

<!—***  This  is  an  example  of  a  course  with  one  block,  containing  two  blocks, 
each  with  two  assignable  [nee  atomic]  content  units.— > 

<block> 

<block  id=“Bl”> 

<identification> 

<title>Building  Big  Things  From  Small  Things</title> 

<description>This  lesson  is  about  content  aggregation</description> 

</identification> 

<block  id=“B2”> 

<identification> 
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<title>Introduction  to  Blocks  101  </title> 

<description>This  Unit  is  about  splitting  and  fusing  atoms</description> 

</identification> 

<au  id=“Al”> 

<identification> 

<title>Building  With  Atoms</title> 

</identification> 

</au> 

<au  id=“A2”> 

<identification> 

<title>Splitting  Atoms  With  Hairs</title> 

</identification> 

</au> 

</block> 

<block  id=“B3”> 

<identification> 

<title>Introduction  to  Leggo  Blocks  107</title> 

<description>This  Unit  is  about  Leggo  Blocks</description> 

</identification> 

<au  id=“A4”> 

<identification> 

<title>Building  With  Leggo  B locks </title> 

</identification> 

</au> 

<au  id=“A5”> 

<identification> 

<title>Connecting  Leggos  Together </title> 

</identification> 

</au> 

</block> 

</block> 

</block> 

</course> 

5.11.5  Multi-Tiered  Example  (Seven  Levels) 

Note:  This  example  is  not  really  a  valid  CSF  record  since  it  omits  some  required 
elements  for  clarity.  Nonetheless,  it  illustrates  deep  nesting  of  levels,  or  tiers. 


<course> 

<globalProp  erties  > 

<externalMetadata> 

<location>army_courseMetadata.xml</location> 
<model>need  example  here</model> 
<source>need  example  here</source> 

</  externalMetadata> 

</globalProperties> 

<block> 

<block> 

<identification> 

<title/> 

<labels> 

<curricular>COURSE</curricular> 

<de  veloper>  ATSC</de  velop  er> 

</labels> 

</identification> 

<block> 

<identification> 

<title/> 

<labels> 

<curricular>MODULE</curricular> 
<developer>  ATSC</  developer> 

</labels> 

</identification> 

<block> 

<identification> 

<title/> 
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<labels> 

<curriculai*>LESSON</curricular> 

<developer>ATSC</developer> 

</labels> 

</identification> 

<block> 

<identification> 

<title/> 

<labels> 

<curricular>LEARNING  OBJECTIVE</curricular> 
<developer>ATSC</developer> 

</labels> 

</identification> 

<au> 

<identification> 

<labels> 

<curricular>LEARNING  STEP</curricular> 
</labels> 

</identification> 

<externalMetadata> 

<location>ARMY  MEDIA  REPOSITORY</location> 
</  externalMetadata> 

</au> 

</block> 

</block> 

</block> 

</block> 

</block> 

</course> 


5. 12  Conformance  Testing 

Conformance  testing  focuses  on  testing  CSF  files  generated  by  an  LMS  or  authoring  tool 
and  verifying  that  the  resulting  CSF  can  be  read  and  interpreted  correctly  by  another 
LMS  or  authoring  tool. 

A  CSF  record  is  expected  to  be  created  from  within  an  LMS  or  course-authoring 
environment.  Within  that  environment,  a  course  may  have  its  own  internal  representation 
of  course  structure  and  its  related  elements.  A  conforming  LMS  or  course  creation 
environment  is  expected  to  map  its  internal  representation  to  a  valid  CSF  record  (as 
defined  by  the  SCORM  CSF  DTD). 

Similarly,  a  conforming  LMS  or  authoring  environment  is  expected  to  read  and  correctly 
interpret  the  SCORM  CSF  format  and  map  the  contents  of  the  CSF  to  its  internal 
representation  as  required.  The  course  should  then  execute  as  intended. 

First,  generated  CSF  records  must  be  validated  against  the  DTD.  Next,  they  must  be 
tested  for  “adequacy.”  The  examples  in  this  document  show  that  it  is  possible  to  produce 
valid  CSF  records  that  are  not,  in  fact,  adequate  to  define  a  course.  Specific  criteria  are 
expected  to  be  developed,  and  these  criteria  should  define  the  necessary  elements  and 
whether  the  values  of  those  elements  adequately  define  a  course.  These  criteria  will 
constitute  the  conformance  “policy”  for  a  particular  community  of  users. 

An  additional  set  of  conformance  tests  will  be  developed  using  dummy  course  examples 
that  can  be  created  in  one  environment,  exported  to  the  CSF,  and  imported  to  another 
environment.  These  dummy  examples  are  to  be  designed  to  test  particular  course 
behavior  and  to  determine  whether  the  CSF  correctly  captures  that  behavior.  A  simple 
test,  for  example,  would  be  for  an  LMS  or  authoring  tool  to  generate  a  CSF  format  and 
then  read  it  back  in.  Having  read  it  back,  the  course  should  behave  exactly  as  before. 
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In  summary,  conformance  testing  consists  of  verifying  that  a  CSF  record  is  valid  (against 
the  DTD)  and  adequate  to  represent  a  course  and  that  the  LMS  or  authoring  tools 
correctly  implement  the  basic  mapping  from  internal  representation  to  the  intermediate 
CSF  (and  back  again). 

Details  and  test  criteria  are  expected  to  be  developed  in  future  versions  of  this  document. 

5.13  Sample  Course  Mappings 

This  section  will  contain  fragments  of  existing  courses  as  they  would  be  represented  in 
the  CSF  format. 
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6. 1  Overview 


A  requirement  of  the  SCORM  is  that  learning  content  be  reusable  across  multiple 
LMSs — regardless  of  the  tools  used  to  create  the  content.  For  this  to  be  possible,  there 
must  be  a  common  way  to  start  content,  a  common  way  for  a  content  to  communicate 
with  an  LMS,  and  predefined  data  elements  that  are  exchanged  between  an  LMS  and 
content  during  its  execution.  This  document  defines  these  three  mechanisms  as  Content 
Launch ,  API  (Application  Program  Interface),  and  Data  Model  (see  Figure  6-1). 


External  systems: 

Content Server(s)  HR,  E-Commerce,  ERP... 


Learning  Server 


AdaH 


^ _ 

Content 

(Assignable 

Unit) 


API 

(Communications  link 
between  content  and  LMS) 


Data  Model 
Actual  data  sent 
back  and  forth 
between  content 
and  LMS 


Learning 

Server 


Figure  6.1 .  Launch,  API,  and  Data  Model  Mechanisms 
as  They  Apply  to  the  SCORM  Architectural  View 

The  Content  Launch  mechanism  defines  a  common  way  for  LMSs  to  start  Web/browser- 
based  content.  It  permits  the  content  to  locate  the  means  to  communicate  status  and 
tracking  information  back  to  the  LMS.  The  communication  takes  place  using  a  common 
API. 
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The  API  mechanism  is  the  vehicle  for  informing  the  LMS  of  the  state  of  the  content  (e.g., 
initialized,  finished,  or  errors),  and  is  used  to  get  and  set  data  between  the  LMS  and  the 
content  (e.g.,  score,  time  limits). 

The  Data  Model  mechanism  is  a  predefined  list  of  data  elements  used  to  track  the  status 
of  content.  In  its  simplest  form,  the  data  model  defines  elements  that  both  the  LMS  and 
content  are  expected  to  “know”  about.  The  LMS  must  maintain  the  status  of  required 
data  elements,  and  the  content  must  use  only  these  data  elements  if  reuse  across  multiple 
systems  is  to  occur. 

6.2  SCORM  and  the  AICC  API  Specification 

The  SCORM  is  based  directly  on  the  runtime  environment  functionality  defined  in 
Appendix  B,  “API-Based  CMI  Communication,”  of  AICC’s  Document  CMI001,  AICC 
CMI  Guidelines  for  Interoperability  (Revision  3.0.1,  24  November  1999.  Appendix  B  of 
this  document  includes  this  specification. 

ADL  collaborated  with  AICC  members  and  participants  to  develop  a  common  Launch 
and  API  specification  and  to  adopt  Web-based  data  elements  from  the  complete  set 
defined  in  the  AICC’s  Semantic  Document  v3.0  (CMI-Sem30.doc).  This  document  is 
available  from  the  IEEE  LTSC’s  Web  page  at  http://www.manta.ieee.org. 

The  following  sections  provide  an  overview  of  the  key  elements  of  the  AICC  API 
specification  as  they  relate  to  the  SCORM. 

6.3  API  Adapter 

The  SCORM  assumes  that  an  LMS  will  supply  an  API  adapter  that  implements  some 
kind  of  communications  transport  between  the  server-side  LMS  and  the  client.  This 
adapter  must  shield  content  from  the  particular  adapter  implementation  details  so  that 
content  (assignable  units)  need  not  have  any  knowledge  of  the  underlying 
communications  infrastructure  and,  instead,  relies  solely  on  the  existence  of  a 
standardized  API. 

For  example,  an  API  adapter  might  be  implemented  as  a  Java  applet  that  looks  similar  to 
the  following: 

public  class  API  extends  applet  { 

private  static  LMSErrorManager  lmsErrorManager; 
private  static  LMSCoreData  lmsCoreData; 
private  static  AUCoreData  auCoreData; 
private  static  boolean  is  LMSInitialized; 
private  URL  servletURL; 
public  void  init() 

{  .  .  .} 

public  String  LMSInitialize (String  param) 

public  String  LMSGetValue (String  element) 

{  .  .  } 

public  void  LMSSetValue (String  element.  String  value) 
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{  .  .  .  } 

public  void  LMSCommitO 

{  .  .  .  } 


public  String  LMSGetLastError ( ) 

{  .  .  .  } 


public  String  LMSGetErrorString ( 

{  .  .  .  } 


String  errorCode) 


public  String  LMSGetDiagnostic (  String  errorCode) 

{  .  .  .  } 


Note  that  an  API  adapter  can  be  implemented  in  other  languages,  such  as  C++,  and 
loaded  as  a  plug-in.  The  API  adapter  implementation  is  expected  to  be  LMS  vendor 
specific.  The  code  fragment  sample  above  is  only  an  example  approach. Figure  6-2a  and 
Figure  6-2b  illustrate  several  different  possible  approaches  for  implementing  an  LMS 
API  adapter: 


Example  1  -  Learning  Management  System  (LMS) 
using  Java  Applet  for  API  Adapter  and  Java 
Servlets  for  Server  Adapter  implementation. 


LMS 


Learning 
Content 
HTML  & 
JavaScript 


Persistence 


Example  2  -  Learning  Management  System  (LMS) 
using  ActiveX  for  API  Adapter  and  Active  Server 
Pages  and  COM  (Common  Object  Model) 
Component(s)  for  Server  Adapter  implementation. 


Figure  6-2a.  Examples  1  and  2  of  Possible  Approaches  for 
Implementing  an  LMS  API  Adapter 
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Example  3-  Learning  Management  System  (LMS) 
with  Shockwave  Plug-in  for  Shockwave  Learning 
Content  and  using  JavaScript  for  API  Adapter  and 
CGI  (Common  Gateway  Interface)  Programs  or 
scripts  for  Server  Adapter  implementation. 


Shockwave 

Web 

Player  Plug-in 

Authorware/ 
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App 
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Scripts 
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Example  4  -  Learning  Management  System  (LMS) 
using  Java  Classes  for  API  Adapter  and  CORBA 
(Common  Object  Request  Broker)  Component(s) 
implemented  in  Java  and/or  C++  for  Server  Adapter 
implementation. 


Browser 


Learning 
Content 
HTML  & 
JavaScript 


LMS 

API 
j  ava 

LMS 
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Figure  6-2b.  Examples  3  and  4  of  Possible  Approaches  for 
Implementing  an  LMS  API  Adapter 

6.4  Content  Launch 

During  the  development  of  the  AICC  API  specification  and  the  ADL  SCORM,  the  AICC, 
IEEE,  and  ADL  participants  examined  the  various  possible  approaches  to  launching 
content  and  initializing  communications  with  LMS  environments.  Many  methods  were 
proposed,  but  most  were  either  too  complex  or  poorly  supported  in  today’s  Web 
environment.  Finally,  a  common  approach  was  proposed  (with  many  thanks  to  Claude 
Ostyn).  This  approach  is  relatively  simple  for  content  authoring  tools  to  support  and  is 
broadly  implementable  with  today’s  browser  technology. 

Nearly  all  browsers — and  certainly  all  of  the  popular  ones — natively  support  JavaScript. 
(The  more  accurate  term  is  actually  ECMAScript,  which  is  the  official  standard  name  of 
JavaScript.)  The  launch  scheme  described  in  Appendix  B  requires  an  LMS  to  launch 
content  from  a  window  that  contains  a  common  API  implementation  (or,  alternatively,  to 
provide  a  parent  frame  that  contains  the  API).  The  API  is  accessible  through  JavaScript 
calls.  This  ensures  that  content  is  “wrapped”  with  the  means  to  establish  communications 
with  the  LMS  once  it  begins  to  execute. 
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The  content  (assignable  unit),  which  may  be  arbitrarily  small  and  simple  or  relatively 
complex,  “connects”  to  an  API  object  to  establish  communications.  Content  Launch 
obtains  the  API  object  by  checking  for  its  existence  on  any  parent  window  or  the  opener 
window.  The  following  JavaScript  example  (see  Appendix  B,  Section  B.2.3.1)  illustrates 
how  content  might  locate  the  API. 

//  returns  the  LMS  API  object  (may  be  null  if  not  found) 

Find  API(  win) 

{ 

if  (win.  API  !=  null) 

return  win.  API; 
else  if  (win.parent  ==  null) 
return  null; 

else 

return  FindAPI(  win.parent); 

} 


//  obtain  the  LMS  API 
API  =  Find  API(  window); 

If  (  API  ==  null) 

API  =  FindAPI(window.opener); 


As  long  as  content  contains  a  binding  to  the  defined  API  object,  an  LMS  can  launch  and 
track  its  execution,  regardless  of  the  tool  used  to  create  it.  Thus,  one  key  function  that 
enables  reuse  is  provided. 

6.5  Application  Program  Interface  (API) 

The  use  of  a  common  API  fulfills  many  of  the  SCORM’s  high-level  requirements  for 
interoperability  and  reuse.  It  provides  a  standardized  way  for  content  to  communicate 
with  learning  management  systems,  yet  it  shields  the  particular  communications 
implementation  from  the  content  developer.  How  the  “insides”  of  an  API  are 
implemented  should  not  matter  to  content  developers  provided  they  use  the  same 
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“outside”  interface.  An  API  “hides”  implementation  details  from  content  and,  therefore, 
promotes  reuse  and  interoperability. 

A  key  aspect  of  the  AICC  API  is  that  it  is  invoked  only  from  within  content.  Once  Web- 
based  content  is  launched,  it  is  assumed  that  it  can  then  “get”  and  “set”  information  with 
an  LMS.  The  functions  of  this  API  are  threefold: 

1.  Execution  state.  The  API  has  initialize()  and  finish( )  function  calls  that  tell  the 
LMS  that  the  content  is  present  and  active  (“I’m  here!  I’m  running!”)  or  that  it 
has  completed  and  ended  (“Tve  stopped,  and  I’m  no  longer  here.”).  These  are  the 
only  two  required  API  calls  that  content  must  make.  This  means  that  an 
extremely  simple  piece  of  content,  such  as  a  media  clip,  would  only  need  to  be 
“wrapped”  with  enough  code  to  embed  an  initialize()  and  finishf)  to  interoperate 
across  multiple  LMS  environments.  Even  large  “chunks”  of  content  might  only 
have  these  two  calls  if  no  other  information  or  data  need  to  be  tracked  by  the 
LMS.  (This  is  not  likely  for  robust  learning  content;  however,  it  is  possible  and 
provided  for.) 

2.  State  management.  The  API  has  four  functions  that  are  used  to  handle  errors 
and  to  force  a  transfer  of  cached  information  back  to  an  LMS: 
LMSGetLastError(),  LMSGetErrorString( errornumber), 
LMSGetDiagnostic(parameter),  and  LMSCommit(parameter). 

3.  Data  transfer.  The  remaining  two  API  functions  are  used  to  transfer  data  to  and 
from  an  LMS:  LMSGetValue(cmi.  cate  gory)  and  LMSSetValue(cmi.  cate  gory, 
value).  Note  that  the  API  is  designed  to  get  and  set  data  values  that  are  separately 
defined  by  an  external  data  model.  The  AICC  specification  defines  one  such  data 
model  here  (and  in  the  AICC  document  referenced  in  Section  6.2)  called  “cmi.” 
Other  data  models  could  also  be  developed  and  used  with  this  API;  thus,  the 
AICC  specification  in  Appendix  B  has  been  designed  to  be  generic.  The  API 
does  not  “know”  about  what  specific  data  that  it  can  set  or  get. 

The  following  code  example  illustrates  how  API  calls  could  be  embedded  within  an 
HTML  page  using  JavaScript.  This  is  only  one  possible  way  to  use  the  API;  there  are 
other  approaches  depending  on  the  type  of  content. 

<SCRIPT  LANGUAGE= JAVASCRIPT  > 

function  loadPage() 

{ 

LMSInitializeO; 

getStartTime(); 

LMSSetValue(  “cmi. core. score. max”,  “5”  ); 

LMSSetValue(  “cmi. core. score. min”,  “0”  ); 

var  student_Name  =  LMSGetValue 

(“cmi. core. student_name” ); 


Table  6-1  is  an  API  table.  Note:  See  Appendix  B  for  detailed  API  definitions  and  data 
types. 
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6.6  Further  Defining  Content  as  “Assignable  Units” 

References  to  “content”  and  “assignable  units”  in  this  document  can  be  confusing  at  first. 
This  confusion  is  compounded  by  the  additional  use  of  “lesson”  in  the  AICC  documents 
and  within  the  CMI  data  model.  All  these  terms  have  roots  in  historical  practices — but 
from  different  groups  and  organizations.  Each  group  has  a  slightly  different  intended 
meaning  for  these  and  other  terms.  This  section  attempts  to  clarify  the  SCORM  concepts 
associated  with  learning  content. 

In  an  important  sense,  the  terms  “lesson”  and  “assignable  unit”  both  refer  to  client-side 
content.  For  client-side  content  to  qualify  as  an  assignable  unit,  however,  it  must  meet 
certain  minimum  requirements,  as  explained  below. 

6.6.1  Content  as  a  “Lesson” 

“Lesson”  has  multiple  definitions  in  the  AICC  CMI  specification,  including: 

•  A  meaningful  division  of  learning  that  is  accomplished  by  a  student  in  a 
continuous  effort — that  is,  at  one  sitting.  That  part  of  the  learning  that  is 
between  designed  breaks.  Frequently  requires  approximately  20  minutes  to  an 
hour. 

•  A  grouping  of  instruction  that  is  controlled  by  a  single  executable  computer 
program. 

•  A  unit  of  training  that  is  a  logical  division  of  a  subchapter,  chapter,  or  course. 

In  a  Web-based  environment,  a  “unit  of  training”  is  likely  to  comprise  many  content 
pieces  and  is  less  likely  to  be  contained  within  a  single  executable  computer  program; 
therefore,  “lesson”  is  a  somewhat  imprecise  term  that  is  subject  to  broad  interpretation. 
The  term  persists,  however,  within  the  CMI  data  model  (see  Section  5.1  of  the  CMI 
Guidelines  for  Interoperability ,  Revision  3.0.1)  for  communications  between  content  and 
LMSs. 

6.6.2  Content  as  an  “Assignable  Unit” 

The  term  “assignable  unit”  also  has  its  roots  in  the  AICC  CMI  specification,  especially 
related  to  representing  course  structure.  The  term  continues  to  be  used  in  the  SCORM 
document — both  in  the  Course  Structure  (Section  5)  and  this  section — but  the  definition 
has  been  narrowed  in  this  document. 

AICC  defines  an  assignable  unit  to  be  both: 

•  The  smallest  unit  the  CMI  [LMS]  system  assigns  and  tracks 

•  A  program  or  lesson  launched  by  the  CMI  [LMS]  system. 

Three  concepts  are  embedded  here.  First,  an  assignable  unit  is  small  and  stand  alone. 
Second,  an  LMS  launches  an  assignable  unit  on  the  client-side.  Finally,  the  LMS  tracks 
the  assignable  unit. 
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The  notion  of  “smallness”  is  subjective.  A  more  useful  way  to  look  at  an  assignable  unit 
is  that  it  has  (by  definition)  no  separate  child  content  components  and  is,  thus,  indivisible. 
An  assignable  unit  could  be  a  very  large  executable  program  or  an  HTML  file  with  just  a 
single  letter  of  text.  Provided  both  examples  implement  the  API  correctly,  either  could 
be  launched  and  tracked  by  an  LMS. 

6.6.3  SCORM  “Assignable  Unit”  Definition 

In  this  document,  the  definition  of  “assignable  unit”  is  extended  to  be  an  arbitrarily  large 
or  small  piece  of  client-side  content  that,  at  a  minimum,  contains  an  Initialize()  and  a 
Finish( )  API  call  and  has  a  means  to  locate  an  API  adapter  (such  as  an  API  “wrapper”  as 
described  in  Section  6.4). 

Thus,  an  assignable  unit  is  content,  but  content  is  not  (in  this  context)  an  assignable 
unit — unless  it  implements  the  API.  Note  that  there  is  no  obligation  to  implement  any  of 
the  other  API  calls.  Those  calls  are  optional  and  depend  on  the  nature  of  the  content. 
However,  the  assignable  unit  must  implement  Initialize()  and  Finish()  calls  to  conform  to 
the  SCORM. 

The  requirement  that  an  assignable  unit  must  implement  the  API  yields  the  following 
benefits: 

•  Any  LMS  that  supports  the  API  can  launch  assignable  units  and  track  them, 
regardless  of  who  generated  them. 

•  Any  conforming  LMS  can  track  any  assignable  unit  and  know  when  it  has  begun 
or  ended. 

•  Any  conforming  LMS  can  launch  any  assignable  unit  in  the  same  manner. 

6.6.4  Defining  a  “Sharable  Courseware  Object”  as  an  Assignable  Unit 

Because  assignable  units  are  required  to  implement  the  API  consistently  to  enable  reuse, 
they  really  are  “Sharable  Courseware  Objects”  (SCOs).  We  continue  to  use  the  term 
“assignable  unit”  because  of  its  AICC  heritage,  but,  in  this  document,  assignable  units 
meet  the  requirements  of  an  SCO  as  defined  in  Section  4.1  of  this  document. 

6.6.5  Small  “Sharable  Courseware  Objects” 

As  discussed  previously,  assignable  units  (a.k.a.  SCOs)  technically  can  be  any  size; 
however,  the  SCORM’ s  specific  intention  is  to  guide  people  toward  the  development  and 
use  of  relatively  small  content  pieces  that  are  suitable  for  reuse  over  time.  During  course 
design,  thought  should  be  given  to  the  smallest  logical  size  of  content  that  might  be 
reused.  Such  content  could  then  form  the  basis  of  content  repositories. 
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6.6.6  Content  Sequencing  Control 

An  implicit  assumption  in  the  SCORM  is  the  notion  that  the  sequencing  of  content  (i.e., 
the  order  in  which  content  is  presented  to  the  student)  is  controlled  solely  by  the  LMS. 
This  is  a  major  departure  from  the  way  courseware  has  been  developed  using  stand-alone, 
CBI.  In  the  past,  courseware  content  typically  embedded  all  the  navigation  information 
that  governs  what  part  of  the  course  the  student  views  next.  In  most  cases,  the  way  in 
which  course  sequencing  was  defined  has  been  unique  to  the  authoring  system  used  to 
construct  the  course;  thus,  it  was  (and  still  is)  difficult  or  impossible  to  share  content 
between  different  authoring  environments. 

Within  the  SCORM,  which  is  deliberately  Web-based,  flow  control  is  assumed  to  be  on 
the  LMS  and  not  within  the  content  itself.  This  is  conceptually  important  because 
content  reuse  cannot  really  happen  if  the  content  has  embedded  information  that  is 
context  specific  to  the  course.  In  this  context,  flow  control  means  that  the  LMS  decides 
what  content  (assignable  unit)  will  next  be  presented  to  the  student.  This  recognizes  that 
some  content  may  make  decisions  (i.e.,  branch)  within  itself,  but  that  kind  of  internal 
flow  is  hidden  from  the  LMS. 

The  determination  of  what  the  student  experiences  is  determined  solely  by  the  LMS  and 
is  defined  in  large  part  by  the  CSF,  as  defined  in  Section  5  of  this  document.  Section  5 
defines  the  information  about  content  that  is  context  specific  to  the  course  (e.g.,  the 
default  sequence  of  content,  prerequisites  that  might  alter  the  delivery  path). 


Summary  Points:  In  the  SCORM,  a  content  assignable  unit  can  only  be  launched  by  an 
LMS.  An  assignable  unit  cannot  itself  launch  other  assignable  units.  An  assignable  unit 
must,  at  a  minimum,  contain  an  initialize()  and  a  finish()  API  call  to  conform  with  the 
SCORM. 


Content  information  independent  of  a  particular  course  (e.g.,  its  generalized  title  and 
description,  intended  use,  and  technical  data  type)  is  contained  in  separate  XML  metadata 
records  (see  Section  7  of  this  document).  Such  data  are  considered  “immutable”  in  that 
these  data  do  not  change  from  use  to  use  but  are  nonetheless  critical  to  discovery  (e.g., 
from  within  a  content  repository)  and  subsequent  incorporation  into  courses. 

6.6.7  Toward  Adaptive  and  Intelligent  Tutoring 

The  development  of  small,  reusable,  and  interoperable  pieces  of  learning  content  and  the 
shift  of  content  flow  control  from  the  client-side  to  the  server-side  establish  the  basis  for 
entirely  new  learning  technologies. 

The  most  obvious  benefits  of  sharability  and  reuse  are  the  possibility  of  large  content 
repositories  and  the  development  of  a  new  “content  economy”  where  SCOs  are  traded 
widely. 

An  even  more  interesting  prospect  is  the  development  of  complex  learning  management 
systems  that  can  assemble,  reorder,  and  redefine  learning  content  to  fit  the  real-time 
needs  of  the  student.  Unfortunately,  the  lack  of  reusable  and  resequenceable  content  has 
delayed  this  vision  from  becoming  reality.  It  is  a  specific  purpose  of  the  SCORM  to 


SCORM  (1.0) 


Page  58 


ADL  Sharable  Courseware  Object  Reference  Model 


provide  a  starting  point  for  the  next  generation  of  advanced  learning  technologies  that  can 
(at  least  in  theory)  be  highly  adaptive  to  student  needs. 

6.7  “CM!”  Data  Model 

The  purpose  of  establishing  a  common  data  model  is  to  ensure  that  a  defined  set  of 
information  about  content  can  be  tracked  by  different  LMS  environments.  If,  for 
example,  it  is  determined  that  tracking  a  student’ s  score  is  a  general  requirement,  it  is 
necessary  to  establish  a  common  way  for  content  to  report  scores  to  LMS  environments 
for  processing.  If  pieces  of  content  use  their  own  unique  scoring  representations,  LMSs 
would  not  know  how  to  receive,  store,  or  process  the  information. 

The  data  model  in  this  section  is  defined  as  the  “CMI”  data  model  because  it  is  derived 
directly  from  the  AICC  CMI  specification.  This  model  was  chosen  for  inclusion  in  the 
SCORM  because  it  is  well  defined  and  has  been  implemented  in  the  past.  The  data 
model  specified  by  AICC  in  Appendix  B  omits  some  of  the  elements  that  applied  to 
earlier  versions  of  the  AICC  specification.  Section  B.8  of  Appendix  B  presents  a  table  of 
the  differences  between  the  original  CMI  data  model  and  the  one  incorporated  in  this 
section,  along  with  the  rationale  for  the  differences. 

Other  data  models  may  be  defined  in  the  future.  This  is  the  reason  that  all  the  elements  in 
this  section  begin  with  “cmi.”  This  signals  to  implementers  that  the  AICC  data  model  is 
in  use.  Alternative  data  models,  if  developed,  would  begin  with  a  different  designation 
(e.g.,  ‘dd\. element  Name  instead  of  cmi  .elementName). 

Three  categories  of  data  elements  are  defined  in  this  section  and  in  more  detail  in 
Appendix  B,  which  is  the  controlling  specification: 

1.  LMS  to  Content  (AU)  Communications 

2.  Content  (AU)  to  LMS  Communications 

3.  Student  Data  Collection. 

These  data  elements  were  developed  so  that  an  LMS  system  could  evaluate  the  student’s 
performance.  Examples  of  data  elements  in  this  category  include  student  comments, 
information  about  a  student’s  performance  on  lesson  objectives  (such  as  mastery  time), 
and  the  path  through  the  content. 

The  LMS  to  Content  (AU)  Communications  data  set  includes  elements  such  as 
student_id,  student_name,  lesson_status,  and  score.  The  AICC  document  also  specifies 
which  elements  require  mandatory  implementation  by  an  LMS  and  which  elements  are 
optional.  (For  conformance  testing  purposes,  those  elements  defined  as  optional  must 
comply  with  the  specification  if  they  are  implemented  by  the  LMS.) 

The  Content  (AU)  to  LMS  Communications  data  set  is  similar  (and  mostly  symmetrical) 
with  the  LMS  to  Content  data  set  but  contains  some  differences  that  make  contextual 
sense.  (Some  data  elements  logically  originate  with  content  only.)  Unlike  the 
requirements  on  the  LMS  side,  all  data  elements  are  “optional”  on  the  content  side 
because  content  may  be  extremely  small  and  “not  very  smart.”  As  a  result,  some  chunks 
of  content  might  not  be  designed  to  be  tracked  in  detail;  however,  if  they  are  to  be 
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tracked,  they  must  conform  to  a  common  data  model  for  reusability  across  multiple  LMS 
environments. 

The  AICC  has  determined  that  the  third  data  set,  Student  Data  Collection,  is  “optional” 
for  both  LMS  environments  and  content  (from  a  conformance  testing  point  of  view). 

6.7.1  “CMI”  LMS  to  Content  (AU)  Data  Model 

Table  6-2  represents  a  subset  of  the  data  model  defined  in  the  AICC  CMI  3.0.1 
document,  which  also  contains  more  complete  definitions  for  each  term.  A  more 
complete  version  of  this  table  is  in  Section  B.4  of  Appendix  B.  All  element  names  are 
preceded  by  “cmi”  to  identify  their  membership  in  the  AICC  “CMI”  data  model. 

This  table  summarizes  the  data  that  an  assignable  unit  may  request  or  “get”  from  the 
LMS.  All  these  elements  are  obtained  using  the  LMSGetValu e(elementName)  API  call. 

The  “LMS  Obligation”  column  represents  the  obligations  of  the  LMS — not  the  learning 
content.  All  data  elements  are  optional  for  content  assignable  units.  Assignable  units  are 
required  only  to  use  Initialize()  and  Finishf).  They  are  not  required  to  use  LMSSetvalue() 
or  LMSGetValue().  This  is  why  all  data  model  elements  are  “optional”  for  content. 


Table  6-2.  Subset  of  the  “CMI”  LMS  to  Content  (AU)  Data  Model 


“CMI”  DATA  MODEL  -  Contextualized  Definition 

LMS 

Element  Name 

LMS  to  Content  (AU)  Communications 

Obli- 

gation 

l-studentjd 

Unique  alpha-numeric  code/identifier  that  refers  to  a  single  user  of 
the  CMI  system.  LMSGetValue(“cmi. core. student  id”) 

Man 

|-student_name 

Normally,  the  official  name  used  for  the  student  on  the  course 
roster.  A  complete  name,  not  just  a  first  name. 
LMSGetValue(“cmi.core.student name”) 

Man 

l-lessonjocation 

This  corresponds  to  the  lesson  exit  point  passed  to  the  CMI 
system  the  last  time  the  student  experienced  the  lesson. 
LMSGetValue(“cmi. core. lesson  location”) 

Man 

|— credit 

Indicates  whether  the  student  is  being  credited  by  the  CMI  system 
for  his  performance  (pass/fail  and  score)  in  this  lesson. 
LMSGetValue(“cmi.core.credit”) 

Man 

|-lesson_status 

This  is  the  current  student  status  as  determined  by  the  CMI 
system,  and  sent  to  the  lesson  when  it  is  launched. 
LMSGetValue(“cmi. core. lesson  status”) 

Man 

|-entry 

Indication  of  whether  the  student  has  been  in  the  lesson  before. 
LMSGetValue(“cmi.  core,  entry”) 

Man 

|-score 

Indication  of  the  performance  of  the  student  during  his  last  attempt 
on  the  lesson.  LMSGetValuefcmi.core. score,  children”) 

Man 

|-|-raw 

Numerical  representation  of  student  performance  in  lesson.  May 
be  unprocessed  raw  score.  LMSGetValuefcmi.core. score. raw”) 

Man 

|-|-max 

The  maximum  score  or  total  number  that  the  student  could  have 
achieved.  LMSGetValue(“cmi.core. score. max”) 

Opt 

|-|-min 

The  minimum  score  that  the  student  could  have  achieved. 
LMSGetValue(“cmi. core. score. min”) 

Opt 
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Table  6-2.  Subset  of  the  “CMI”  LMS  to  Content  (AU)  Data  Model  (Continued) 


“CMI”  DATA  MODEL  -  Contextualized  Definition 

LMS 

Element  Name 

LMS  to  Content  (AU)  Communications 

Obli- 

gation 

|~total_time 

Accumulated  time  of  all  the  student  sessions  in  the  lesson. 
LMSGetValuefcmi.core.time”) 

Man 

|-lesson_mode 

Identification  of  student-related  information  that  may  be  used  to 
change  the  behavior  of  the  lesson. 

LSMGetValue(“cmi. core. lesson  mode”) 

Opt 

suspend_data 

Unique  information  generated  by  the  lesson  during  previous  uses, 
that  is  needed  for  the  current  use. 

LMSGetValuefcmi. suspend  data”) 

Man 

launch_data 

Unique  information  generated  at  the  lesson’s  creation  that  is 
needed  for  every  use.  LMSGetValue(“cmi. launch  data”) 

Man 

comments 

Instructor  comments  directed  at  the  student  that  the  lesson  may 
present  to  the  student  when  appropriate. 

LMSGetValuefcmi.  comments”) 

Opt 

[-coursejd 

Alpha  numeric  sequence  that  provides  a  unique  label  for  a  course. 
LMSGetValuefcmi. evaluation.course  id  “) 

Opt 

|-comments 

Identifies  if  the  student’s  comments  on  a  lesson  can  be  collected 
and  made  available  by  the  LMS  in  a  separate  file. 
LMSGetValuefcmi. evaluation. comments.) 

Opt 

l-interactions 

Identifies  what  detailed  information  of  a  student’s  interactions  in  a 
lesson  can  be  collected. 

LMSGetValuefcmi. evaluation. interactions,  children”) 

Opt 

|-objectives_ 

status 

Identifies  what  detailed  information  on  lesson  objectives  can  be 
collected. 

LMSGetValuefcmi. evaluation. objectives  status,  children”) 

Opt 

|— path 

Identifies  what  detailed  information  can  be  collected  on  the  path 
through  the  lesson  taken  by  the  student. 

LMSGetValuefcmi. evaluation. path,  children”) 

Opt 

l-performance 

Identifies  what  detailed  information  can  be  collected,  on  the 
student’s  performance  in  complex  scenarios,  such  as  simulations. 
LMSGetValuefcmi. evaluation. performance,  children”) 

Opt 

l-id 

A  developer-defined,  lesson-specific  identifier  for  an  objective. 
LMSGetValuefcmi. objectives. n. id”) 

Opt 

[-scores 

The  score  obtained  by  the  student  after  each  attempt  to  master 
the  objective.  LMSGetValuefcmi. objectives. n. scores,  count') 

Opt 

|-|-raw 

Numerical  representation  of  student  performance  after  each 
attempt  on  the  objective.  May  be  unprocessed  raw  score. 
LMSGetValuefcmi. objectives. n. scores. n. raw”) 

Opt 

H~max 

The  maximum  score  or  total  number  that  the  student  could  have 
achieved.  LMSGetValuefcmi. objectives. n. scores. n. max”) 

Opt 

[— |— min 

The  minimum  score  that  the  student  could  have  achieved. 
LMSGetValuefcmi. objectives. n. scores,  n. min”) 

Opt 

l-statuses 

The  status  obtained  by  the  student  after  each  attempt  to  master 
the  objective.  LMSGetValuefcmi. objectives. n. status. n”) 

Opt 

SCORM  (1.0) 


Page  61 


ADL  Sharable  Courseware  Object  Reference  Model 


Table  6-2.  Subset  of  the  “CMI”  LMS  to  Content  (AU)  Data  Model  (Continued) 


“CMI”  DATA  MODEL  -  Contextualized  Definition 

LMS 

Element  Name 

LMS  to  Content  (AU)  Communications 

Obli- 

gation 

|-attempt_number 

Number  of  times  the  student  has  been  in,  or  previously  used  the 
lesson.  LMSGetValue(“cmi. student  data. attempt  number”) 

Opt 

|-mastery_score 

The  passing  score,  as  determined  outside  the  lesson. 
LMSGetValuefcmi. student  data. mastery  score”) 

Opt 

|-max_time_ 

allowed 

The  amount  of  time  the  student  is  allowed  to  have  in  the  current 
attempt  on  the  lesson. 

LMSGetValuefcmi. student  data. max  time  allowed”) 

Opt 

time  limit  action 

What  the  lesson  is  to  do  when  the  max  time  allowed  is  exceeded. 
LMSGetValue(“cmi. student  data. time  limit  action”) 

Opt 

|-attempt_records 

Student’s  performance  after  previous  times  in  the  lesson. 
LMSGetValue(“cmi.student_data.attempt_records._ch/7c/ren”) 
LMSGetValuefcmi. student  data. attempt  records,  count’) 

Opt 

|-|-lesson_scores 

The  score  obtained  by  the  student  after  each  previous  attempt. 
LMSGetValue(“cmi. student  data.attempt  records. n. lesson  score”) 

Opt 

I--I- 

lesson  statuses 

Indication  of  the  status  of  the  lesson  after  each  attempt. 
LMSGetValue(“cmi.student data.attempt records.n.lesson status”) 

Opt 

[—city 

Portion  of  student’s  current  address. 

LMSGetValue(“cmi. student  demographics.city”) 

Opt 

|-class 

A  predefined  training  group  to  which  a  student  belongs. 
LMSGetValuefcmi. student  demographics.class”) 

Opt 

|-company 

Student’s  place  of  employment. 

LMSGetValue(“cmi. student  demographics.company”) 

Opt 

l-country 

Portion  of  student’s  current  address. 

LMSGetValuefcmi. student  demographics.country”) 

Opt 

|-experience 

Information  on  the  student’s  past  that  might  be  required  by  a 
lesson  to  determine  what  to  present,  or  what  presentation 
strategies  to  use. 

LMSGetValuefcmi. student  demographics. experience”) 

Opt 

|-familiar_name 

An  informal  title  that  may  be  used  to  address  the  student. 
LMSGetValuefcmi. student  demographics. familiar  name”) 

Opt 

|-instructor_name 

Name  of  the  person  responsible  for  the  student’s  understanding  of 
the  material  in  the  lesson. 

LMSGetValue(“cmi. student  demographics. instructor  name”) 

Opt 

[-title 

Title  of  the  position  or  the  degree  currently  held  by  the  student. 
LMSGetValuefcmi. student  demographics. title”) 

Opt 

|-native_language 

The  language  used  in  the  student’s  country  of  origin. 

LMSGetValue  (“cmi. student  demographics. native  language”) 

Opt 

|-state 

Segment  of  a  country,  also  called  province,  district,  canton,  and  so 
forth.  LMSGetValue(“cmi. student  demographics. state”) 

Opt 

|-street_address 

Portion  of  student’s  current  address. 

LMSGetValue(“cmi. student  demographics. street  address”) 

Opt 

l-telephone 

Telephone  number  of  a  student. 

LMSGetValue(“cmi. student  demographics. telephone”) 

Opt 

|-years_ 

experience 

Number  of  years  the  student  has  performed  in  current  or  similar 
position. 

LMSGetValue(“cmi.student_demographics.years_experience”) 

Opt 
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Table  6-2.  Subset  of  the  “CMI”  LMS  to  Content  (AU)  Data  Model  (Continued) 


“CMI”  DATA  MODEL  -  Contextualized  Definition 

LMS 

Element  Name 

LMS  to  Content  (AU)  Communications 

Obli- 

gation 

|-years_ 

experience 

Number  of  years  the  student  has  performed  in  current  or  similar 
position. 

LMSGetValue(“cmi. student  demographics. years  experience”) 

Opt 

-audio 

Sound  on/off  and  volume  control. 

LMSGetValue(“cmi. student  preference. audio”) 

Opt 

-language 

Identifies  in  what  language  the  information  should  be  delivered. 
LMSGetValue(“cmi. student  preference. language”) 

Opt 

-lesson_type 

Indicates  suitability  of  preferences  to  current  lesson. 
LMSGetValue(“cmi. student  preference. lesson  type”) 

Opt 

-speed 

Pace  of  content  delivery. 

LMSGetValue(“cmi.student preference. speed”) 

Opt 

-text 

Written  content  visibility  control. 

LMSGetValue(“cmi. student  preference,  text”) 

Opt 

-text_color 

Written  content  foreground  and  background  hue. 

LMSGetValuefcmi. student  preference. text  color”) 

Opt 

-textjocation 

Position  of  text  window  on  the  screen. 

LMSGetValue(“cmi. student  preference. text  location”) 

Opt 

-text_size 

Magnitude  of  the  written  content  characters  on  screen. 
LMSGetValue(“cmi. student  preference. text  size”) 

Opt 

-video 

Motion  picture  tint  and  brightness  on  the  screen. 
LMSGetValue(“cmi.student preference.  video”) 

Opt 

-windows 

Size  and  location  of  video,  help,  glossary,  and  so  forth  windows. 
LMSGetValue(“cmi.student_preference.n.  windows”) 

Opt 

6.7.2  “CMI”  Content  (AU)  to  LMS  Data  Model 

Table  6-3  represents  a  subset  of  the  data  model  defined  in  the  AICC  CMI  3.0.1 
document,  which  also  contains  more  complete  definitions  for  each  term.  A  more 
complete  version  of  this  table  is  provided  in  Section  B.5  of  Appendix  B.  All  element 
names  are  preceded  by  “cmi”  to  identify  their  membership  in  the  “CMI”  data  model. 

This  table  summarizes  the  data  that  an  assignable  unit  may  send  to  the  LMS.  All  these 
elements  are  sent  to  the  LMS  using  the  LMSSetValue(elementName)  API  call. 

The  “LMS  Obligation”  column  represents  the  obligations  of  the  LMS,  not  the  learning 
content.  All  data  elements  are  optional  for  content  assignable  units.  Assignable  units  are 
required  only  to  use  Initialize()  and  Finish().  They  are  not  required  to  use  LMSSetValue() 
or  LMSGetValue().  This  is  why  all  data  model  elements  are  “optional”  for  content. 


Table  6-3.  “CMI”  Content  (AU)  to  LMS  Data  Model 


“CMI”  DATA  MODEL  -  Contextualized  Definition 

LMS 

Element  Name 

Content  (AU)  to  LMS  Communications 

Obli- 

gation 

l-lessonjocation 

This  identifies  the  point  where  the  student  leaves  the  lesson. 
LMSSetValue(“cmi.core.lesson_location”,  value) 

Man 
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Table  6-3.  “CMI”  Content  (au)  to  LMS  Data  Model 


“CMI”  DATA  MODEL  -  Contextualized  Definition 

LMS 

Element  Name 

Content  (AU)  to  LMS  Communications 

Obli- 

gation 

|-lesson_status 

This  is  the  student  status  when  he  leaves  the  lesson. 
LMSSetValue(“cmi. core. lesson  status”,  value) 

Man 

J— exit 

An  indication  of  how  or  why  the  student  left  the  lesson. 
LMSSetValue(“cmi. core. exit”,  value) 

Man 

|-score 

Indication  of  the  performance  of  the  student  during  his  time  in  the 
lesson. 

Man 

|-|-raw 

Numerical  representation  of  student  performance  in  lesson.  May 
be  unprocessed  raw  score. 

LMSSetValue(“cmi. core. score. raw”,  value) 

Man 

|~|~max 

The  maximum  score  or  total  number  that  the  student  could  have 
achieved.  LMSSetValue(“cmi.core. score. max”) 

Opt 

min 

The  minimum  score  that  the  student  could  have  achieved. 
LMSSetValue(“cmi.  core,  score,  min”) 

Opt 

|-session_time 

Time  spent  in  the  lesson  during  the  session  that  is  ending. 
LMSSetValue(“cmi.core.time”,  value) 

Man 

suspend_data 

Unique  information  generated  by  the  lesson,  that  is  needed  for 
future  uses.  Passed  to  the  CMI  system  to  hold  and  to  return  the 
next  time  the  student  starts  this  lesson. 

LMSSetValue(“cmi. suspend  data”,  value) 

Man 

comments 

Student’s  written  remarks  recorded  during  the  current  use  of  the 
lesson.  LMSSetValue(“cmi.comments.n  value) 

Opt 

l-id 

A  developer  defined,  lesson-specific  identifier  for  an  objective. 
LMSSetValue(“cmi. objectives. n. id”,  value) 

Opt 

|-scores 

The  score  obtained  by  the  student  after  each  attempt  to  master 
the  objective. 

Opt 

|-|--raw 

Numerical  representation  of  student  performance  after  each 
attempt  on  the  objective.  May  be  unprocessed  raw  score. 
LMSSetValuefcmi. objectives. n. scores. n. raw”,  value) 

Opt 

|--|-max 

The  maximum  score  or  total  number  that  the  student  could  have 
achieved.  LMSSetValue(“cmi. objectives. n. scores. n. max”,  value) 

Opt 

min 

The  minimum  score  that  the  student  could  have  achieved. 
LMSSetValuefcmi.objectives.n.scores.n.min”,  value) 

Opt 

l-statuses 

The  status  obtained  by  the  student  after  each  attempt  to  master 
the  objective.  LMSSetValue(“cmi. objectives. n. status. n”,  value) 

Opt 

]-tries_during_ 

lesson 

Total  number  of  efforts  to  complete  the  lesson  or  selected 
segment. 

LMSSetValue(“cmi. student  data.tries  during  lesson”,  value) 

Opt 

[-tries 

Data  related  to  each  try. 

Opt 

j-|-score 

The  score  at  the  completion  of  each  attempt. 

Opt 

j— j— | — raw 

Numerical  representation  of  student  performance  after  each 
attempt  on  the  objective.  May  be  unprocessed  raw  score. 
LMSSetValue(“cmi. student  data. tries. n. score. raw”,  value) 

Opt 

|-|-|-max 

The  maximum  score  or  total  number  that  the  student  could  have 
achieved. 

LMSSetValue(“cmi.student_data. tries. n. score. max”,  value) 

Opt 
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Table  6-3.  “CMI”  Content  (au)  to  LMS  Data  Model  (Continued) 


“CMI”  DATA  MODEL  -  Contextualized  Definition 

LMS 

Element  Name 

Content  (AU)  to  LMS  Communications 

Obli- 

gation 

|-|-|-min 

The  minimum  score  that  the  student  could  have  achieved. 
LMSSetValue(“cmi. student  data. tries. n. score. min”,  value) 

Opt 

|—|— status 

The  status  of  the  lesson  or  segment  after  each  attempt. 
LMSSetValue(“cmi. student  data. tries. n. status  value) 

Opt 

Hh-time 

Length  of  time  required  for  each  attempt  on  a  lesson  or  segment. 
LMSSetValue(“cmi. student  data. tries. n. time  value) 

Opt 

|-language 

Identifies  in  what  language  the  information  should  be  delivered. 
LMSSetValue(“cmi.student_preference. language”,  value) 

Opt 

|-lesson_type 

Indicates  suitability  of  preferences  to  current  lesson. 
LMSSetValue(“cmi. student  preference. lesson  type”,  value) 

Opt 

|-speed 

Pace  of  content  delivery. 

LMSSetValue(“cmi. student  preference. speed”,  value) 

Opt 

[—text 

Written  content  visibility  control. 

LMSSetValue(“cmi. student  preference. text”,  value) 

Opt 

|-text_color 

Written  content  foreground  and  background  hue. 

LMSSetValue(“cmi. student  preference. text  color”,  value) 

Opt 

l-textjocation 

Position  of  text  window  on  the  screen. 

LMSSetValue(“cmi. student  preference. text  location”,  value) 

Opt 

|-text_size 

Magnitude  of  the  written  content  characters  on  screen. 
LMSSetValuefcmi. student  preference. text  size”,  value) 

Opt 

|-video 

Motion  picture  tint  and  brightness  on  the  screen. 
LMSSetValue(“cmi.student preference. video”,  value) 

Opt 

|-windows 

Size  and  location  of  video,  help,  glossary,  etc.  windows. 
LMSSetValue(“cmi. student  preference. n. windows”,  value) 

Opt 

6.7.3  Student  Data  Collection 

Table  6-4  represents  a  subset  of  the  data  model  defined  in  the  AICC  CMI  3.0.1 
document,  which  also  contains  more  complete  definitions  for  each  term.  A  more 
complete  version  of  this  table  is  provided  in  Section  B.6  of  Appendix  B.  All  element 
names  are  preceded  by  “cmi”  to  identify  their  membership  in  the  “CMI”  data  model. 

This  table  summarizes  the  data  that  an  assignable  unit  may  send  to  the  LMS  related  to 
interactions  with  the  student.  All  these  element  values  are  sent  using  the 
hMSSetValue(elementName)  API  call. 

The  LMS  obligation  column  represents  the  obligations  of  the  LMS,  not  the  learning 
content.  All  data  elements  are  optional  for  content  assignable  units.  Assignable  units  are 
required  only  to  use  Initialize()  and  Finish();  they  are  not  required  to  use  LMSSetvalue() 
or  LMSGetVaIue().  This  is  why  all  data  model  elements  are  “optional”  for  content. 

This  entire  category  of  the  data  model  is  optional. 
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Table  6-4.  Student  Data  Collection  Data  Model 


Element  Name 

Student  Data  Collection  Table 

LMS 

Contextualized  Definition 

Obli- 

gation 

lessonjd 

Alphanumeric  label  supplied  by  the  developer. 

LMSSetValue(“cmi. evaluation. lesson  id”,  value) 

Opt 

date 

The  calendar  day  on  which  the  data  is  created. 

LMSSetValue(“cmi. evaluation. date”,  value) 

Opt 

|— time 

Indication  of  when  the  comment  is  made. 
LMSSetValue(“cmi.evaluation.comments.n.time  “,  value) 

Opt 

|— location 

Indication  of  where  in  the  content  the  comment  is  made. 
LMSSetValue(“cmi.evaluation.comments.n. location  “,  value) 

Opt 

l-content 

The  recorded  statement  of  a  student. 
LMSSetValue(“cmi.evaluation.comments.n.content  value) 

Opt 

[—id 

Unique  alphanumeric  label  created  by  the  content  developer. 
LMSSetValue(“cmi. interactions. n. id  “,  value) 

Opt 

l-objectivejds 

Indication  of  any  objectives  associated  with  the  interaction. 
LMSSetValue(“cmi. interactions. n. objective  ids.n”,  value) 

Opt 

[-time 

Indication  of  when  the  interaction  is  available  to  the  student. 
LMSSetValue(“cmi. interactions. n. time  “,  value) 

Opt 

Hype 

Indication  of  which  category  of  interaction  is  recorded. 

LMSSetValue(“cmi. interactions. n. type  “,  value) 

Opt 

|-responses 

Expected  student  feedback  in  the  interaction. 

|-|-description 

Definition  of  possible  student  response. 

LMSSetValue(“cmi. interactions. n. response. n.description”,  value) 

Opt 

value 

How  the  system  judges  the  described  response. 

LMSSetValue(“cmi. interactions. n. response. n.value”,  value) 

Opt 

[--weighting 

Factor  that  is  used  to  identify  the  relative  importance  of  one  interaction 
compared  to  another. 

LMSSetValue(“cmi. interactions. n. weighting  “,  value) 

Opt 

|-student_ 

response 

Description  of  the  computer-measurable  action  of  a  student  in  an 
interaction. 

LMSSetValue(“cmi. interactions. n. student  response  “,  value) 

Opt 

|— result 

Judgment  of  the  student’s  response. 

LMSSetValue(“cmi. interactions. n. result  “,  value) 

Opt 

l-latency 

The  time  from  the  presentation  of  the  stimulus  to  the  completion  of  the 
measurable  response. 

LMSSetValue(“cmi. interactions. n. latency  “,  value) 

Opt 

l-locationjd 

Identification  of  where  the  student  is  in  the  content. 
LMSSetValue(“cmi.path.n.location id”,  value) 

Opt 

[-time 

Indication  of  when  the  student  entered  the  content  segment. 
LMSSetValue(“cmi. path. n. time”,  value) 

Opt 
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Table  6-4.  Student  Data  Collection  Data  Model  (Continued) 


Element  Name 

Student  Data  Collection  Table 

LMS 

Contextualized  Definition 

Obli- 

gation 

|-status 

A  record  of  the  student’s  performance  in  a  segment  each  time  he  leaves 
that  element  LMSSetValuefcmi. path. n. status”,  value) 

Opt 

|-why_left 

The  reason  a  student  departed  an  element  in  the  content. 
LMSSetValue(“cmi. path. n. why  left”,  value) 

Opt 

|--time_in _ 

element 

How  long  the  student  spent  in  the  element. 
LMSSetValue(“cmi.path.n.time_in_element”,  value) 

Opt 

6.7.4  “CMI”  Data  Types  and  Controlled  Vocabularies 

A  data  type  definition  exists  for  each  element  in  the  CMI  data  model.  Section  B.7  of 
Appendix  B  summarizes  the  data  type  definitions.  Sections  B.4,  B.5,  and  B.6  define  the 
data  type  for  each  of  the  data  model  elements.  These  definitions  define  how  the  API  and 
data  model  must  be  implemented. 

In  addition  to  data  types,  some  data  model  elements  are  predefined  with  bounded 
vocabularies  of  possible  values.  Table  6-5  summarizes  the  vocabulary  type  and  values 
(from  Section  B.7,  AICC  CMI  3.0.1  Appendix  B).  Definitions  for  each  vocabulary  are 
contained  in  Sections  5.1  and  5.2  of  the  AICC  CMI  3.0.1  specification. 


Table  6-5.  Vocabulary  Type  and  Values 


Vocabulary  Type 

Members  of  Vocabulary 

Mode 

normal 

review 

browse 

Status 

passed 

completed 

failed 

incomplete 

browsed 

not  attempted 

Exit 

time-out 

suspend 

logout 

Why-left 

student  selected 

lesson  directed 

exit 

directed  departure 

Credit 

credit 

no  credit 

Entry 

ab-initio 

resume 

Time  Limit  Action 

exit 

continue 

message 

no  message 

Interaction 

true-false 

multiple  choice 

fill  in  the  blank 

matching 

simple  performance 

likert 

sequencing 

unique 

numeric 

Result 

correct 

wrong 

unanticipated 

neutral 

x.x  (CMIDecimal) 
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6.8  Conformance  Testing 

Three  things  need  to  be  tested  for  runtime  environment  conformance  with  the  SCORM: 
support  of  launch,  correct  implementation  of  the  API,  and  correct  usage  of  the  data 
model.  The  responsibilities  for  the  LMS  and  content  are  different. 

Testing  an  LMS  (or  course  authoring  environment)  for  conformance: 

•  Can  the  LMS  launch  a  known  conforming  course  assignable  unit? 

•  Does  the  LMS  fully  support  the  mandatory  API  functionality? 

•  Does  the  LMS  support  the  mandatory  and  optional  data  elements  in  the  data 
model? 

Testing  content  for  conformance: 

•  Can  the  content  be  launched  by  a  known  conforming  LMS  test  environment? 

•  Does  the  content  correctly  implement  the  minimum  API  functionality  [i.e., 
initicilizeO  and  terminate( )]? 

•  Does  the  content  correctly  implement  other  API  calls  (if  any)? 

•  Does  the  content  exchange  conforming  data  over  the  API? 

Detailed  test  criteria  and  test  software  are  expected  to  be  developed  and  included  in  a 
future  version  of  this  document. 
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7.  Metadata 

7. 1  Overview 

Metadata — data  about  data — for  learning  content,  have  been  under  development  within 
several  national  and  international  organizations  over  the  past  few  years.  The  purpose  of 
metadata  is  to  provide  a  common  means  to  describe  things  (electronically)  so  that 
“learning  objects”  (however  they  are  defined)  can  be  self  defined,  searched,  and  found. 
Learning  content  is  only  one  area  of  metadata  application.  Metadata  is  also  actively 
being  developed  in  all  aspects  of  Web-based  content  and  commerce. 

ADL  has  looked  to  the  IEEE  LOM  subgroup  and  the  IMS  project  as  the  harmonizing 
bodies  that  are  defining  metadata  specifically  for  learning  content.  These  groups,  which 
have  been  working  collaboratively  over  the  past  few  years,  have  developed  a  core 
specification  to  which  this  document  refers. 

The  IMS  and  IEEE  specifications  (http://www.imsproject.org/metadata  and 
http://ltsc.ieee.org/doc/wgl2/WD3)  define  a  standard  “dictionary”  of  metadata  element 
definitions  along  with  recommendations  for  “best  practices”  and  XML  bindings 
(critically  important  for  implementation).  These  documents,  however,  do  not  specifically 
propose  how  individual  communities  of  users  might  elect  to  apply  these  metadata 
definitions  to  their  content  models. 

The  ADL  SCORM  references  and  abides  by  the  IEEE/IMS  definitions  and  goes  one  step 
further  to  apply  these  definitions  to  the  three  components  of  the  SCORM  model:  raw 
media,  content,  and  external  course.  This  mapping  of  standardized  definitions  from 
IEEE/IMS  to  the  SCORM  model  provides  the  missing  link  between  general 
specifications  and  specific-content  models.  Many  thanks  go  to  Wayne  Hodgins,  Tom 
Wason,  Thor  Anderson,  and  Steve  Griffin  for  their  efforts  in  establishing  these  key 
specifications. 

The  following  sections  define  the  SCORM  application  of  IEEE/IMS  definitions. 

7.2  Definitions  of  SCORM  Metadata  Elements 

The  following  definitions  “map”  how  metadata  are  to  be  applied  to  the  SCORM  “content 
model.”  In  all  cases,  the  IEEE/IMS  documents  are  referenced  and  applied  to  the  various 
components  of  the  ADL  SCORM  model. 

7.2.1  Raw  Media  Metadata 

Raw  media  metadata  can  be  applied  to  so-called  “raw  media”  assets  (e.g.,  illustrations, 
documents,  or  media  streams)  that  provide  descriptive  information  about  the  raw  media 
independent  of  courseware  content.  These  metadata  are  used  to  facilitate  reuse  and 
discoverability — principally  during  content  creation  of  media  elements  within,  for 
example,  a  media  repository. 
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•  Metadata  that  describe  raw  media  elements  in  a  noncontext-specific  way 

•  Information  that  can  be  searched  externally,  such  as  media  asset  title,  description, 
date  of  creation,  and  version 

•  Information  that  can  be  used  to  create  a  searchable  repository  of  sharable  media 
elements. 


7.2.2  Content  Metadata 


Content  metadata  can  be  applied  to  Web-based  content,  which  provides  descriptive 
information  about  the  content  independent  of  a  particular  course.  These  metadata  are 
used  to  facilitate  reuse  and  discoverability  of  content  within,  for  example,  a  content 
repository. 


•  Metadata  that  describe  a  [sharable]  “chunk”  of  content 

•  Content  metadata  not  related  to  a  specific  course  structure  (i.e.,  context- 
independent  metadata) 

•  Information  that  can  be  searched  externally,  such  as  content  asset  title, 
description,  and  version. 


7.2.3  External  Course  Metadata 


External  course  metadata  are  external  metadata  that  describe  a  course  package  for 
searching  (enabling  discoverability)  within  a  courseware  repository  and  for  providing 
descriptive  information  about  the  course. 


•  Information  about  a  course  as  a  whole  that  describes  what  it  is  for,  who  can  use  it, 
who  controls  it,  and  so  forth 

•  Information  that  can  be  searched  externally,  such  as  the  course  title,  course 
description,  and  version. 


7.2.4  SCO  Structure  Format  (Assignment  Hierarchy)  Metadata 


Metadata  within  a  representation  (such  as  XML)  of  a  course  structure  that  can  be  used  to 
define  all  the  course  elements,  structure,  and  external  references  necessary  to  move  a 
course  from  one  LMS  environment  to  another. 


•  Metadata  described  with  the  specific  assignments  at  different  levels  within  the 
lesson  plan  hierarchy 

•  Course  element  metadata  within  a  particular  course  hierarchy  that  is  context 
specific  to  that  course  hierarchy. 
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7.3  SCORM  Metadata  Mapping 

Table  7-1  lists  each  of  the  IEEE  LOM  elements  as  defined  in  the  IEEE  LTSC  Working 
Group  PI 484. 12  WD3  document.  This  document  is  accessible  at  Internet  address 
http://ltsc.ieee.org/doc/wgl2AVD3  and  is  included  as  Appendix  C  of  this  document.  The 
right-three  columns  define  how  each  metadata  element  is  to  be  applied  to  the  SCORM 
and  which  elements  should  be  used  when  building  metadata  records  for  raw  media, 
content,  and  entire  courses. 


Table  7-1.  IEEE  LOM  Elements 


Note  for  Table  7-1 :  Blank  =  not  used;  M  =  mandatory;  O  =  optional;  SEL  =  (IMS)  Standard 
Extension  Library. 


SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

1 .  General 

This  category  groups  the  general  information 
that  describes  this  resource  as  a  whole. 

1.1  Identifier 

A  globally  unique  label  that  identifies  this 
resource. 

This  is  reserved  and  shall  not  be  used, 
because  there  is  no  specified  method  for  the 
creation  of  a  globally  unique  identifier. 

SERVED 

1.2  Title 

Name  given  to  this  resource. 

This  element  may  be  an  already  existing  one  or 
it  may  be  created  by  the  indexer  ad  hoc. 

This  element  shall  correspond  with  the  Dublin 
Core  element  DC. Title. 

CORE 

M 

M 

M 

1 .3  Catalog  Entry 

This  subcategory  defines  an  entry  within  a 
catalogue  (i.e.,  a  listing  identification  system) 
assigned  to  this  resource. 

This  subcategory  is  intended  to  describe  this 
resource  according  to  some  known  cataloging 
system  so  that  it  may  be  externally  searched  for 
and  located  according  to  the  methodology  of 
the  specified  system. 

This  subcategory  may  be  used  as  a  functional 
replacement  for  the  element  1.1:  Identifier,  as 
that  is  currently  reserved.  In  this  way,  it  shall 
be  used  to  store  the  Dublin  Core  element 

DC. Identifier. 

One  of  the  catalog  entries  can  be  generated 
automatically  by  the  tool. 

1.3.1  Catalog 

The  name  of  the  catalogue  (i.e.,  listing 
identification  system). 

CORE 

0 

M 

M 
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Table  7-1.  IEEE  LOM  Elements  (Continued) 


SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

1.3.2  Entry 

Actual  string  value  of  the  entry  within  the 
catalogue  (i.e.,  listing  identification  system). 

CORE 

0 

M 

M 

1.4  Language 

The  primary  human  language  used  within  this 
resource  to  communicate  to  the  intended  user. 

An  indexation  tool  may  provide  a  useful  default. 

This  elementshall  correspond  with  the  Dublin 
Core  elementDC. Language. 

CORE 

0 

0 

0 

1.5  Description 

A  textual  description  of  the  content  of  this 
resource. 

This  elementshall  correspond  with  the  Dublin 
Core  elementDC. Description. 

CORE 

M 

M 

M 

1 .6  Keywords 

Keywords  or  phrases  describing  this  resource. 

This  element  should  not  be  used  for 
characteristics  that  can  be  described  by  other 
elements. 

SEL 

0 

M 

M 

1 .7  Coverage 

The  span  or  extent  of  such  things  as  time, 
culture,  geography,  or  region  that  applies  to  this 
resource. 

This  elementshall  correspond  with  the  Dublin 
Core  elementDC. Cove  rage. 

SEL 

1.8  Structure 

Underlying  organizational  structure  of  this 
resource. 

Restricted  vocabulary: 

l=User_defined 

2=See_classification 

3=Collection 

4=M  ixed 

5=Linear 

6=H  iera  rchical 

7=N  etworked 

8=B  ranched 

9=P  arceled 

10=Atomic. 

SEL 
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Table  7-1.  IEEE  LOM  Elements  (Continued) 


SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

1.9  Aggregation 

Level 

The  functional  granularity  of  this  resource. 

Level  0  means  smallest  level  of  aggregation 
(e.g.,  raw  media  data  or  fragments). 

Level  1  refers  to  a  collection  of  atoms  (e.g.,  an 
HTML  documentwith  some  embedded  pictures 
ora  lesson). 

Level  2  indicates  a  collection  of  level  1 
resources  (e.g.,  a  'web' of  HTML  documents, 
with  an  index  page  that  links  the  pages 
together  or  a  unit). 

Finally,  level  3  refers  to  the  largest  level  of 
granularity  ( e.g.,  a  course). 

SEL 

0 

?TBD 

2  LifeCycle 

This  category  describes  the  history  and  current 
state  of  this  resource  and  those  who  have 

affected  this  resource  during  its  evolution. 

2.1  Version 

The  edition  of  this  resource. 

CORE 

0 

M 

M 

2.2  Status 

The  state  or  condition  this  resource  is  in. 

Restricted  vocabulary:  restricted  vocabulary: 

l=User_defined 

2=See_classification 

3=D  raft 

4=F  inal 

5=Revised 

6=Unavailable. 

SEL 

0 

M 

M 

2.3  Contribute 

This  subcategory  describes  those  people  or 
organizations  that  have  affected  the  state  of 
this  resource  during  its  evolution  (includes 
creation,  edits  and  publication). 

This  subcategory  is  different  from  3.3: 

Contribute. 
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SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

2.3.1  Role 

Kind  of  contribution. 

This  element  should  include  exactly  one 
instance  of  Author 

Best  practice  list: 

l=User_defined 

2=See_classification 

3=Author 

4=P  ublisher 

5=Unknown 

6  initiator 

7=Terminator 

8=Validator 

9  =E  d  ito  r 

10=G raphical  Designer 
ll=Technical  Implementer 

12=C  ontent  Provider 

13=Technical  Validator 

14=E  ducational  Validator 

15=Script  Writer 

16=lnstructional  Designer. 

It  is  recommended  that  exactly  one  instance  of 
Author  exists. 

CORE 

0 

0 

0 

2.3.2  Entity 

The  identification  of  and  information  about  the 
people  or  organizations  contributing  to  this 
resource,  most  relevant  first. 

If  2.3. liifeCycle. Contribute. Role  equals 

Author,  then  the  entity  should  be  a  person  and 
this  element  shall  correspond  with  the  Dublin 

Core  element  DC. Creator. 

If  2. 3. liifeCycle. Contribute. Role  equals 

P  ublisher,  then  the  entity  should  be  an 
organization  and  this  elementshall  correspond 
with  the  Dublin  Core  element  DC. Publisher. 

If  2. 3. liifeCycle. Contribute. Role  is  not  equal  to 
Author  or  Publisher,  then  this  elementshall 
correspond  with  the  Dublin  Core  element 

DC. Contributor. 

If  the  entity  is  an  organization,  then  it  should  be 
a  university  department,  company,  agency, 
institute,  and  so  forth  under  whose 
responsibility  the  contribution  was  made. 

CORE 

0 

0 

0 
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SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

2.3.3  Date 

The  date  of  the  contribution. 

CORE 

0 

0 

0 

3  MetaMetaData 

This  category  describes  the  specific  information 
about  this  metadata  record  itself  (rather  than 
the  resource  thatthis  record  describes). 

This  category  describes  such  things  as  who 

created  this  metadata  record,  how,  when  and 

with  what  references. 

This  is  not  the  information  that  describes  the 
resource  itself. 

3.1  Identifier 

A  globally  unique  label  that  identifies  this 
metadata  record. 

This  is  reserved  and  shall  not  be  used,  as  there 
is  no  specified  method  for  the  creation  of  a 
globally  unique  identifier. 

SERVED 

3.2  Catalog  Entry 

This  subcategory  defines  an  entry  within  a 
catalogue  (i.e.,  listing  identification  system), 
given  to  the  metadata  instance. 

This  category  is  intended  to  describe  this 
metadata  instance  according  to  some  known 
cataloging  system  so  that  it  may  be  externally 
searched  for  and  located  according  to  that 
system. 

This  element  may  be  used  as  a  functional 
replacement  for  tine  currently  reserved  element 

3.  RMetaMetaData.  Identifier. 

One  of  the  catalog  entries  may  be  generated 
automatically  by  the  tool. 

SEL 

3.2.1  Catalog 

The  name  of  the  catalogue  (i.e.,  listing 
identification  system).  Generally  system 
generated. 

SEL 

3.2.2  Entry 

Actual  string  value  of  the  entry  in  the  catalogue. 
This  element  is  usually  generated  by  the 
system. 

SEL 

3.3  Contribute 

This  subcategory  describes  those  people  or 
organizations  that  have  affected  the  state  of 
this  metadata  instance  during  its  evolution 
(includes  creator  and  validator). 

This  element  is  different  from 

2. 3:Lifecycle.  Contribute. 

SEL 
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SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

3.3.1  Role 

Kind  of  contribution. 

Exactly  one  instance  of  creator  should  exist. 

Open  vocabulary  with  best  practice  list: 

l=User_defined 

2=See_classification 

3=Creator 

4=Validator. 

It  is  recommended  that  exactly  one  instance  of 
creator  exists. 

SEL 

3.3.2  Entity 

The  identification  of  and  information  about  the 
people  or  organizations  contributing  to  this 
metadata  instance,  most  relevant  first. 

SEL 

3.3.3  Date 

The  date  of  the  contribution. 

SEL 

3.4  Metadata  Scheme 

The  name  and  version  of  the  authoritative 
specification  used  to  create  this  metadata 
instance. 

This  element  may  be  user  selectable  or  system 
generated. 

If  multiple  values  are  provided,  then  the 
metadata  instance  shall  conform  to  multiple 
metadata  schemes. 

CORE 

M 

M 

M 

3.5  Language 

Language  of  this  metadata  instance.  This  is 
the  default  language  for  all  LangString  values  in 
this  metadata  instance. 

CORE 

4  Technical 

This  category  describes  the  technical _ 

requirements  and  characteristics  of  this _ 

resource. 

4.1  Format 

Technical  data  type  of  this  resource. 

This  element  shall  be  used  to  identify  the 
software  needed  to  access  the  resource. 

Restricted  vocabulary:  MIME  type  or  "non¬ 
digital."  Can  be  used  to  identify  the  software 
needed  to  access  the  resource. 

For  example,  video/mpeg,  application/x- 
toolbook,  text/html. 

CORE 

M 

M 

M 

4.2  Size 

The  size  of  the  digital  resource  in  bytes.  Only 
the  digits  'O'...  '9'  should  be  used.  The  unit  is 
bytes,  not  MBytes,  GB,  and  so  forth. 

This  elementshall  refer  to  the  actual  size  of  this 
resource  and  notto  the  size  of  a  compressed 
version  of  this  resource. 

SEL 

0 

0 

0 
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SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

4.3  Location 

A  string  that  is  used  to  access  this  resource.  It 
may  be  a  location  (e.g.,  Universal  Resource 
Locator),  or  a  method  that  resolves  to  a  location 
(e.g.,  Universal  Resource  Identifier). 

Preferable  Location  first. 

This  is  where  the  learning  resource  described 
by  this  metadata  instance  is  physically  located 
(e.g.,  http://host/id) 

CORE 

M 

M 

M 

4.4  Requirements 

This  subcategory  describes  the  technical 
capabilities  required  in  order  to  use  this 
resource. 

If  there  are  multiple  requirements,  then  all  are 
required,  i.e.  the  logical  connector  is  AND. 

4.4.1  Type 

The  technology  required  to  use  this  resource 
(i.e.,  hardware,  software,  network,  and  so 
forth). 

Open  vocabulary  with  best  practice: 

l=User_defined 

2=See_classification 

3=0perating  System 

4=Browser. 

SEL 

0 

0 

0 
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SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

4.4.2  Name 

Name  of  the  required  technology  to  use  this 
resource. 

The  value  for  this  element  may  be  derived  from 

4. 1:T echnical. Format  automatically  (e.g., 
"video/mpeg" implies  "Multi-OS"). 

If  Type  =  'Operating  System,' then  best  practice 
list: 

l=User_defined 

2=See  classification 

3=P  C -DO  S 

4=MS-Windows 

5=MacOS 

6=Unix 

7=Multi-0S 

8=0ther 

9=None. 

If  Type  =  'Browser,'  then  best  practice  list: 

10=Any 

11=N etscape  Communicator 

12=M  icrosoft  Internet  Explorer 

13=0  pera. 

If  other  type,  then  open  vocabulary. 

SEL 

0 

0 

0 

4.4.3  Minimum 

Version 

Lowest  possible  version  of  the  required 
technology  to  use  this  resource. 

SEL 

0 

0 

0 

4.4.4  Maximum 

Version 

Highest  version  of  the  technology  known  to 
support  the  use  of  this  resource. 

SEL 

0 

0 

0 

4.5  Installation 
Remarks 

Description  on  how  to  install  this  resource. 

SEL 

0 

0 

0 

4.6  Other  Platform 
Requirements 

Information  about  other  software  and  hardware 
requirements. 

SEL 

0 

0 

0 

4.7  Duration 

Time  a  continuous  resource  takes  when  played 
at  intended  speed. 

This  is  especially  useful  for  sounds,  movies  or 
animations. 

SEL 

0 

0 

0 
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SCORM 


SCORM 


5  Educational 

This  category  describes  the  key  educational  or 

pedagogic  characteristics  of  this  resource. 

This  is  the  pedagogical  information  essential  to 

those  involved  in  achieving  a  quality  learning 
experience.  The  audience  for  this  metadata 

includes  teachers,  managers,  authors,  and 

learners. 

5.1  Interactivity  Type 

The  flow  of  interaction  between  this  resource 
and  the  intended  user. 

SEL 

Raw 

Media 


SCORM 

Content 


External 

Course 


In  an  expositive  resource,  the  information  flows 
mainly  from  this  resource  to  the  learner. 
Expositive  documents  are  typically  used  for 
learning-  by-  reading. 

In  an  active  resource,  information  also  flows 
from  the  learner  to  this  resource.  Active 
documents  are  typically  used  for  learning-by- 
doing. 

Activating  links  to  navigate  in  hypertext 
documents  is  not  considered  as  an  information 
flow.  Thus,  hypertext  documents  are  expositive. 

Restricted  vocabulary: 

l=User_defined 

2=See_classification 

3=Active 

4=Expositive 

5=M  ixed 

6=Undefined. 


Expositive  documents  include  essays,  video 
clips,  all  kinds  of  graphical  material  and 
hypertext  documents.  Active  documents 
include  simulations,  questionnaires  and 
exercises. 
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SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

5.2  Learning 

Resource  Type 

Specific  kind  of  resource,  most  dominant  kind 
first. 

This  element  shall  correspond  with  the  Dublin 
Core  element  "Resource  Type. "The  vocabulary 
is  adapted  for  the  specific  purpose  of  learning 
objects. 

Open  vocabulary  with  best  practice: 

l=User_defined 

2=See_classification 

3=Exercise 

4=S  imulation 

5=Questionnaire 

6=Diagram 

7=Figure 

8=Graph 

9=lndex 

10=Slide 

11=T  able 

12=N  arrative  Text 

13=Exam 

14=Experiment 

15=P  roblemStatement 

16=S  elfAssesment. 

SEL 

0 

0 

0 

5.3  Interactivity  Level 

This  element  shall  define  the  degree  of 
interactivity  between  the  end  user  and  this 
resource,  with  0  defined  as  'Very  Low,"l 
defined  as  "Low," 2  defined  as  "Medium," 3 
defined  as  "High, "and  4  defined  as  'Very  High." 

SEL 

5.4  Semantic  Density 

This  element  shall  define  a  subjective  measure 
of  this  resource's  usefulness  as  compared  to  its 
size  or  duration,  with  0  defined  as  'Very  Low,"  1 
defined  as  "Low," 2  defined  as  "Medium," 3 
defined  as  "High, "and  4  defined  as  'Very  High." 

SEL 
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SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

5.5  Intended  End 

User  Role 

Principal  user(s)  for  which  this  resource  was 
designed,  most  dominant  first. 

A  learner  works  with  a  resource  in  order  to 
learn  something.  An  author  creates  or 
publishes  a  resource.  A  manager  manages  the 
delivery  of  this  resource  (e.g.,  a  university  or 
college).  The  documentfor  a  manager  is 
typically  a  curriculum. 

Restricted  vocabulary: 

0=Teacher 

l=Author 

2=Learner 

3=Manager. 

SEL 

5.6  Context 

The  principal  environmentwithin  which  the 
learning  and  use  of  this  resource  is  intended  to 
take  place. 

Open  vocabulary  with  best  practice: 

l=User_defined 

2=See_classification 

3=P rimary  Education 

4=Secondary  Education 

5=H igher  Education 

6=University  First  Cycle 

7=University  Second  Cycle 

8=University  Postgrade 

9=Technical  School  FirstCycle 

10=Technical  School  Second  Cycle 

11=P rofessional  Formation 

12=Continuous  Formation 

13=Vocational  Training 

14=0  ther. 

SEL 
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SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

5.7  Typical  Age 

Range 

Age  of  the  typical  intended  user. 

This  element  shall  refer  to  developmental  age, 
if  that  would  be  different  from  chronological 
age.  The  age  of  the  learner  is  important  for 
finding  resources,  especially  for  school  age 
learners  and  their  teachers. 

When  applicable,  the  string  should  be  formatted 
as  minage-maxage  or  minage-.  (This  is  a 
compromise  between  adding  three  subfields 
(minAge,  maxAge  and  description)  and  having 
just  a  free  text  field.) 

Various  reading  age  schemes,  IQ's  or 
developmental  age  measures  should  be 
represented  through  the  ^Classification 
category 

SEL 

5.8  Difficulty 

This  element  defines  how  hard  it  is  to  work 
through  this  resource  for  the  typical  target 
audience,  with  0  defined  as  'Very  Easy,"  1 
defined  as  "Easy, "2  defined  as  "Medium, "3 
defined  as  "Difficult,"  and  4  defined  as  'Very 
Difficult." 

SEL 

5.9  Typical  Learning 
Time 

Approximate  or  typical  time  it  takes  to  work  with 
this  resource. 

SEL 

0 

0 

5.10  Description 

Comments  on  how  this  resource  is  to  be  used 
(e.g.,  teacher  guidelines  that  come  with  a 
textbook). 

SEL 

5.11  Language 

The  human  language  used  by  the  typical 
intended  user  of  the  resource. 

LanguagelD  =Langcode(‘- 'Subcode)*,  with 
Langcode  a  two-letter  language  code  as 
defined  by  IS0639  and  subcode  a  country  code 
from  IS 0 3166  (e.g.,  "en",  "en-GB",  "de",  “fr-CA", 
"it"). 

SEL 

6  Rights 

This  category  describes  the  intellectual  property 

The  intent  is  to  reuse  results  of  onqoing  work  in 
the  Intellectual  Property  Right  and  e-commerce 
communities.  This  category  currently  provides 
the  absolute  minimum  level  of  detail  only. 
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SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

6.1  Cost 

Whether  use  of  the  resource  requires  payment. 

Restricted  vocabulary: 

l=User_defined 

2=See_classification 

3=yes 

4=no. 

CORE 

M 

M 

M 

6.2  Copyright  and 
Other  Restrictions 

Whether  copyright  or  other  restrictions  apply  to 
the  use  of  this  resource. 

Restricted  vocabulary: 

l=User_defined 

2=See_classification 

3=yes 

4=no. 

CORE 

M 

M 

M 

6.3  Description 

Comments  on  the  conditions  of  use  of  this 
resource. 

CORE 

0 

0 

0 

7  Relation 

This  category  defines  the  relationship  between 

this  resource  and  other  targeted  resources,  if 

any.  To  define  multiple  relationships  there  may 

be  multiple  instances  of  this  category.  If  there  is 

more  than  one  target  resource,  each  tarqet  is 

covered  by  a  new  relationship  instance. 

7.1  Kind 

Nature  of  the  relationship  between  this 
resource  and  the  target  resource,  identified  by 

7. 2:Relation. Resource. 

This  element  shall  correspond  with  the  Dublin 
Core  element  DC  .Relation. 

Best  practice  list  from  Dublin  Core: 

l=User_defined 

2=See  classification 

3=lsPartOf 

4=H  asP  art 

5=lsVersionOf 

6=H  asVersion 

7=lsF  ormatOf 

8=H  asF  ormat 

9=References 

10=lsReferencedBy 

ll=lsBasedOn 

12=lsBasisF  or 

13=Requires 

14=lsRequiredBy. 

SEL 
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SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

7.2  Resource 

The  target  resource  that  this  relationship 
references. 

7.2.1  Identifier 

Unique  Identifier  of  the  target  resource. 

This  is  reserved  and  shall  not  be  used. 

RE- 

SERVED 

7.2.2  Description 

Description  of  the  target  resource. 

SEL 

8  Annotation 

This  category  provides  comments  on  the 

educational  use  of  this  resource,  who  created 
this  annotation  and  when. 

When  multiple  annotations  are  needed,  multiple 

instances  of  this  category  may  be  used. 

8.1  Person 

The  person  who  created  this  annotation. 

SEL 

8.2  Date 

Date  that  this  annotation  was  created. 

SEL 

8.3  Description 

The  content  of  this  annotation. 

SEL 

9  Classification 

This  category  describes  where  this  resource  is 

placed  within  a  particular  classification  system. 

To  define  multiple  classifications,  there  may  be 
multiple  instances  of  this  category. 

If  9. 1  Classification. Purpose  equals  Discipline, 

this  cateqory  shall  correspond  with  the  Dublin 

Core  elementDC.  Subject. 

9.1  Purpose 

The  purpose  of  classifying  this  resource. 

Open  vocabulary  with  best  practice: 

l=User_defined 

2=See_classification 

3=Discipline 

4=ldea 

5=P  rerequisite 

6=E ducational  Objective 

7=Accessibility  Restrictions 

8=E  ducational  Level 

9=Skill  Level 

10=Security  Level. 

CORE 

M 

M 

9.2  TaxonPath 

This  subcategory  describes  a  taxonomic  path  in 
a  specific  classification  system.  Each 
succeeding  level  is  a  refinement  in  the 
definition  of  the  higher  level. 

There  may  be  different  paths,  in  the  same  or 
different  classifications,  that  describe  the  same 
characteristic. 

A  taxonomy  is  a  hierarchy  of  terms  or  phrases 
that  are  taxons. 
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SCORM 

Raw 

Media 

SCORM 

Content 

SCORM 

External 

Course 

9.2.1  Source 

The  name  of  the  classification  system. 

This  element  may  use  any  recognized  "official" 
taxonomy,  any  user-defined  taxonomy.  An 
indexation  or  query  tool  may  provide  the  top- 
level  entries  of  a  well-established  classification 
(LOC,  UDC,  DDC,  and  so  forth). 

SEL 

9.2.2  Taxon 

This  subcategory  describes  a  particular  term 
within  a  hierarchical  classification  system  or 
taxonomy.  A  taxon  is  a  node  that  has  a  defined 
label  or  term.  A  taxon  may  also  have  an 
alphanumeric  designation  or  identifier  for 
standardized  reference.  Either  or  both  the  label 
and  the  entry  may  be  used  to  designate  a 
particular  taxon. 

An  ordered  list  of  T axons  creates  a  taxonomic 
path  (i.e.  'taxonomic  stairway":  this  is  a  path 
from  a  more  general  to  more  specific  entry  in  a 
classification). 

A  TaxonPath  shall  have  a  depth  from  1  to  9. 
Normal  values  should  be  defined  as  values 
between  2  and  4 

(e.g., 

Physics/Acoustics/Instruments/Stethoscope; 

Medicine/Diagnostics/Instruments/Stethoscope) 

9. 2.2.1  ID 

The  identifier  of  the  taxon,  such  as  a  number  or 
letter  combination  provided  by  the  source  of  the 
taxonomy  (e.g.,  300). 

SEL 

9. 2.2.2  Entry 

The  textual  label  of  the  taxon  (e.g.,  Social 
Sciences). 

SEL 

9.3  Description 

This  is  the  description  of  the  resource  relative 
to  the  stated  9.  ^Classification.  Purpose  of  this 
specific  classification,  such  as  discipline,  idea, 
skill  level,  educational  objective,  and  so  forth. 

CORE 

M 

M 

9.4  Keywords 

These  are  the  keywords  and  phrases 
descriptive  of  the  resource  relative  to  the  stated 

9.  ^Classification.  Purpose  of  this  specific 
classification,  such  as  accessibility,  security 
level,  and  so  forth,  most  relevant  first. 

CORE 

M 

M 

7.4  Stand-Alone  XML  Metadata  Records 

It  is  expected  that  each  of  the  three  categories  of  SCORM  metadata  (raw  media,  content, 
and  external  course)  will  take  the  form  of  stand-alone  XML  records  that  conform  to  the 
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IMS  Learning  Resource  Meta-data  XML  Binding  Specification,  Version  1.0  (included  as 
Appendix  D). 

SCORM  metadata  records  are  expected  to  be  valid,  well-formed  XML  documents  based 
on  the  DTD  in  Appendix  D;  however,  the  only  metadata  elements  that  should  be  used  are 
those  listed  as  “mandatory”  or  “optional”  as  defined  in  Section  7.3. 

7.5  XML  Schema,  Namespaces,  and  Extensibility 

The  use  of  XML  DTDs  as  a  means  to  ensure  conformance  is  understood  to  be  highly 
problematic  in  the  Internet  community.  DTDs  fail  to  provide  adequate  mechanisms  for 
extensions  and  do  not  guarantee  interoperability. 

New  approaches  for  defining  interoperable  and  flexible  XML  records  are  emerging  from 
organizations  such  as  XML  Schema  and  name  spacing  being  developed  within  the  W3C 
(http://www.w3c.org).  The  W3C  Home  Page  provides  a  reference  to  an  XHTML  version 
1.0.  These  developments  are  beyond  the  scope  of  this  document.  It  is,  nonetheless, 
expected  that  the  XML  bindings  referenced  in  this  document  that  today  depend  on  DTDs 
will  later  be  converted  to  comply  with  mainstream  XML  practices  once  they  are  defined 
and  adopted. 

This  means  that  XML  metadata  records  produced  using  the  specifications  included  in  this 
document  will  eventually  need  to  be  converted  to  newer  XML  formats  as  these  formats 
become  defined.  This  conversion  is  not  expected  to  be  particularly  difficult  and  can 
probably  be  performed  semi-automatically  using  simple  software  tools. 

7.6  Conformance  Testing 

Conformance  testing  of  metadata  records  consists  of  verifying  that  a  metadata  record  is  a 
valid  IMS/IEEE  record  and  that  it  has  the  mandatory  or  optional  elements  for  its  use  as 
specified  within  the  SCORM  for  raw  media,  content,  and  external  course  metadata 
records. 

7.7  XML  Examples 

The  following  examples  are  empty  XML  files  based  on  the  IMS  XML  DTD  [see 
Appendix  D]  but  only  contain  elements  that  apply  to  the  ADL  SCORM  for  each  of  the 
three  categories. 

7.7.1  Empty  Raw  Media  XML  Metadata  Record 

<?xml  version="l . 0"  encoding="UTF-8 " ?> 

< ! DOCTYPE  RECORD  SYSTEM  "IMS_MD01 . dtd"  > 

<RECORD  xmlns="http : / / www . imspro ject . org/metadata/ "> 

<ME  T AME  T ADATA> 

<! — Mandatory  Element  SCORM  RMMD — > 

<METADATASCHEME / > 


SCORM  (1.0) 


Page  86 


ADL  Sharable  Courseware  Object  Reference  Model 


</ ME TAME TAD AT A > 

<GENERAL> 

<TITLE> 

<! --Mandatory  element  SCORM  RMMD — > 

CLANGSTRING/ > 

</TITLE> 

<CATALOGENTRY> 

<! — Optional  elements  SCORM  RMMD — > 

<CATALOGUE / > 

<ENTRY> 

< LANGS TRING/> 

</ENTRY> 

</ CATALOGENTRY> 

< LANGUAGE > 

<! --Optional  element  SCORM  RMMD--> 

</ LANGUAGE > 

<DESCRIPTION> 

<! --Mandatory  element  SCORM  RMMD — > 

CLANGSTRING/ > 

< /DESCRIP TION> 

<KEYWORDS> 

<! — Optional  element  SCORM  RMMD — > 

CLANGSTRING/ > 

< / KEYWORD  S  > 

</GENERAL> 

<LIFECYCLE> 

<VERSION> 

<! --Optional  element  SCORM  RMMD--> 

<LANGSTRING/> 

</VERSION> 

<STATUS> 

<! — Optional  element  SCORM  RMMD — > 

CLANGSTRING/ > 

< / STATUS> 

<CONTRIBUTE> 

<!--ALL  lifecycle  elements  optional  SCORM  RMMD — > 
<ROLE> 

< LANGS TRING/> 

</ROLE> 

<CENTITY> 

<! — Optional  element  SCORM  RMMD — > 

</ CENTITY> 

<DATE> 
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<! — Optional  element  SCORM  RMMD — > 

<DATETIME/> 

</DATE> 

</CONTRIBUTE> 

</LIFECYCLE> 

<TECHNICAL> 

<FORMAT> 

<! — Mandatory  element  SCORM  RMMD — > 
<LANGSTRING/> 

</ FORMAT > 

<SIZE> 

<! --Optional  element  SCORM  RMMD — > 
</SIZE> 

<LOCATION> 

<! --Optional  element  SCORM  RMMD--> 
</LOCATION> 

<REQUIREMENTS> 

<TYPE> 

<LANGSTRING/> 

</TYPE> 

<! — Optional  element  SCORM  RMMD — > 
<MINIMUMVERSION> 

<! — Optional  element  SCORM  RMMD — > 
</MINIMUMVERSION> 

<MAXIMUMVERSION> 

<! — Optional  element  SCORM  RMMD — > 
< /MAX I MUM VERS I ON> 

</REQUIREMENTS> 

< INST ALLAT I ONREMARKS  > 

<! --Optional  element  SCORM  RMMD — > 
CLANGSTRING/ > 

< / INS  TALLAT I ONREMARKS  > 
<OTHERPLATFORMREQUIREMENTS> 
<LANGSTRING> 

<! — Optional  element  SCORM  RMMD — > 
</ LANGS TRING> 

</OTHERPLATFORMREQUIREMENTS> 

<DURATION> 

<! — Optional  element  SCORM  RMMD — > 
<DATETIME/> 

</DURATION> 

</TECHNICAL> 

<EDUCATIONAL> 
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< LEARN INGCONTEXT> 

<! --Optional  element  SCORM  RMMD — > 
<LANGSTRING/> 

</LEARNINGCONTEXT> 

</EDUCATIONAL> 

<RIGHTS> 

<COST> 

<! — Mandatory  element  SCORM  RMMD — > 
<LANGSTRING/> 

</COST> 

<COPYRIGHTOROTHERRESTRICTIONS> 

<! — Mandatory  element  SCORM  RMMD — > 
<LANGSTRING/> 

</ COP YRIGHTOROTHERRE STRICT I ONS> 

< DE SCRIPT I ON> 

<! — Optional  element  SCORM  RMMD — > 
<LANGSTRING/> 

< /DESCRIPT I ON> 

</RIGHTS> 

</RECORD> 

7.7.2  Empty  Content  XML  Metadata  Record 

<?xml  version="l . 0"  encoding="UTF-8"?> 

< ! DOCTYPE  RECORD  SYSTEM  "IMS_MD01 . dtd"  > 

<RECORD  xmlns="http : / /www . imspro ject . org/metadata/"> 
<ME TAME TAD ATA> 

< ! — Mandatory  Element  SCORM  CONTENTMD — > 
<METADATASCHEME / > 

< /METAMETADATA> 

<GENERAL> 

<TITLE> 

< ! — Mandatory  element  SCORM  CONTENTMD — > 
<LANGSTRING/> 

</TITLE> 

<CATALOGENTRY> 

<! --Mandatory  elements  SCORM  CONTENTMD — > 
<CATALOGUE/> 

<ENTRY> 

<LANGSTRING/> 

</ENTRY> 

< / CATALOGENTRY> 

< LANGUAGE > 
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< ! — Optional  element  SCORM  CONTENTMD — > 

</ LANGUAGE > 

<DE SCRIPT ION> 

<! --Mandatory  element  SCORM  CONTENTMD — > 

CLANGSTRING/ > 

</DESCRIPTION> 

<KEYWORDS> 

< ! — Mandatory  element  SCORM  CONTENTMD — > 

CLANGS TRING/> 

</KEYWORDS> 

<AGGREGATIONLEVEL> 

< ! — Optional  element  SCORM  CONTENTMD — > 
</AGGREGATIONLEVEL> 

</GENERAL> 

<LIFECYCLE> 

CVERS ION> 

<! --Mandatory  element  SCORM  CONTENTMD--> 

CLANGS TRING/> 
c/VERSION> 

CSTATUS> 

c! — Mandatory  element  SCORM  CONTENTMD — > 

CLANGSTRING/ > 
c/STATUS> 

CCONTRIBUTE> 

c!--ALL  lifecycle  elements  optional  SCORM  CONTENTMD — > 
CR0LE> 

CLANGSTRING/ > 
c/ROLE> 

CCENTITY> 

c! — Optional  element  SCORM  CONTENTMD — > 

</ CENTITY> 

CDATE> 

c! — Optional  element  SCORM  CONTENTMD — > 

CDATETIME/> 
c/DATE> 
c/ CONTRIBUTE > 

C/LIFECYCLE> 

CTECHNICAL> 

CFORMAT> 

c ! --Mandatory  element  SCORM  CONTENTMD--> 

CLANGS TRING/> 
c/FORMAT> 

CSIZE> 
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< ! — Optional  element  SCORM  CONTENTMD — > 

</ SIZE> 

CLOCATION  type="URI"> 

< ! — Optional  element  SCORM  CONTENTMD — > 
</LOCATION> 

<REQUIREMENTS> 

<TYPE> 

<LANGSTRING/> 

</TYPE> 

< ! — Optional  element  SCORM  CONTENTMD — > 
<MINIMUMVERS ION> 

< ! — Optional  element  SCORM  CONTENTMD — > 
</MINIMUMVERSION> 

<MAXIMUMVERS ION> 

< ! — Optional  element  SCORM  CONTENTMD — > 
< /MAXIMUMVERS I ON> 

</REQUIREMENTS> 

< INS  T ALLAT I ONREMARKS  > 

< ! — Optional  element  SCORM  CONTENTMD — > 
<LANGSTRING/> 

< / INS  TALLAT I ONREMARKS  > 
<OTHERPLATFORMREQUIREMENTS> 

<LANGSTRING> 

< ! — Optional  element  SCORM  CONTENTMD — > 
</ LANGS TRING> 

</OTHERPLATFORMREQUIREMENTS> 

<DURATION> 

< ! — Optional  element  SCORM  CONTENTMD — > 
<DATETIME/> 

</DURATION> 

</TECHNICAL> 

<EDUCAT IONAL> 

<LEARNINGCONTEXT> 

< ! — Optional  element  SCORM  CONTENTMD — > 
CLANGS TRING/> 

</LEARNINGCONTEXT> 

<  T YP I CALLE ARN I NGT IME  > 

< ! — Optional  element  SCORM  CONTENTMD — > 
<DE SCRIPT I ON> 

CLANGSTRING/ > 

< /DESCRIPT ION> 
c/TYP ICALLEARNINGTIME> 

</EDUCATIONAL> 
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<RIGHTS> 

<COST> 

< ! — Mandatory  element  SCORM  CONTENTMD — > 

<LANGSTRING/> 

</COST> 

< COP YRIGHTOROTHERRE STRICT I ONS> 

<! --Mandatory  element  SCORM  CONTENTMD — > 

< LANGS TRING/> 

< /COP YRIGHTOROTHERRE STRICT IONS > 

<DESCRIPTION> 

< ! — Optional  element  SCORM  CONTENTMD — > 

<LANGSTRING/> 

< /DESCRIPTIONS 
</RIGHTS> 

<CLASS IF I CATIONS 
<PURPOSES 

<! --Mandatory  element  SCORM  CONTENTMD — s 
<LANGSTRING/S 
</PURPOSES 
<DESCRIPTIONS 

< ! — Mandatory  Element  SCORM  CONTENTMD — s 
< LANGS TRING/s 
< /DESCRIPTIONS 
<KEYWORDSS 

<! --Mandatory  element  SCORM  CONTENTMD — s 
< LANGS TRING/s 
</KEYWORDS> 

< / C  LAS  S I F I CAT I ONS 
</RECORDs 

7.7.3  External  Course  Metadata  XML  Record 

External  course  metadata  and  content  metadata  currently  have  the  same  mandatory  and 
optional  elements.  This  could  change  during  evaluation  of  these  specifications;  therefore, 
a  placeholder  is  provided  here.  The  issue  at  hand  is  that  overhead  associated  with 
metadata  tags  may  result  in  some  elements  being  eliminated  from  content  or  course 
records.  This  must  be  determined  through  trial  implementations. 
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8.  Sample  SCORM  Code 

The  release  of  SCORM  version  1.0  includes  a  package  of  samples  that  illustrate  various 
aspects  of  this  document.  They  are  available  for  free  and  may  be  downloaded  from 
http://www.adlnet.org. 

Note:  The  sample  code  described  in  this  section  will  be  updated  and  expanded  over  time. 
Be  sure  to  download  the  most  recent  version  and  view  the  read  me. htm  file  for  new 
information.  The  samples  described  in  this  section  may  have  been  superseded  by  newer 
versions  by  the  time  this  document  has  been  published.  You  are  free  to  use  and  modify 
these  samples  any  way  you  wish.  If  you  create  new  or  improved  samples,  please  send 
them  to  secretariat®  adlnet.org  so  others  may  benefit  from  what  you  have  learned. 

This  release  includes  a  sample  LMS  and  content,  and  an  XML  CSF  editor. 

8. 1  Sample  LMS  and  Content 

The  sample  LMS  (See  Figure  8-1)  is  intended  to  provide  an  example  implementation  of 
the  concepts  described  in  the  ADL  SCORM  version  1.0.  This  sample  was  developed 
over  an  extremely  short  period  of  time  to  provide  an  illustration  of  the  concepts  described 
in  the  SCORM.  It  will  be  continuously  expanded.  The  main  focus  during  this  iteration 
of  development  has  been  the  runtime  environment  communication  between  the  LMS  and 
assignable  units  using  the  API  mechanism  described  in  the  SCORM.  It  is  not  a  complete 
LMS  implementation. 
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Done 


Welcome  to  the  Advanced  Distributed  Learning  (ADL)  Sample 
Learning  Management  System  (LMS).  This  sample  LMS  is  intended 
to  provide  a  reference  implementation  of  the  concepts  described  in 
the  ADL  Shareable  Courseware  Object  Model  (SCORM). 

This  sample  was  developed  over  an  extremely  short  period  of  time 
for  the  purpose  of  illustrating  the  concepts  described  in  the  SCORM 
and  will  be  expanded  as  time  permits.  It  is  not  a  complete  LMS 
implementation.  The  main  focus  during  this  iteration  of  development 
has  been  the  runtime  environment  communication  between  the  LMS 
and  assignable  units  (AUs)  using  the  API  mechanism  described  in 
the  SCORM. 

We  have  chosen  to  implement  this  version  of  the  sample  LMS  as  a 
web -based  client/server  application  using  HTML,  Javascript,  Java 
Applets  and  Java  Servlets. 
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Figure  8-1.  Sample  LMS 
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Several  shortcuts  have  been  taken  in  this  version: 

•  Robust  exception  and  error  handling  have  not  been  included  in  this  sample  code. 

•  There  are  a  near  infinite  number  of  possible  LMS  implementations.  This  version 
of  the  sample  LMS  was  implemented  as  a  Web-based  client/server  application 
using  HTML,  JavaScript,  Java  applets,  and  Java  servlets. 

•  This  sample  LMS  supports  only  a  single  student  and  a  single  course  with  one 
lesson  at  this  time. 

•  Concurrent  access  is  not  supported. 

This  sample  code  consists  of  the  following  components: 

•  LMS  Server.  This  is  implemented  using  java  servlets. 

•  LMS  Client.  This  is  implemented  using  Java  applets,  HTML,  and  JavaScript. 

•  Sample  Course.  This  is  implemented  using  HTML  and  JavaScript. 

8.1.1  LMS  Server 

The  LMS  server  functionality  (see  Figure  8-2)  is  implemented  using  Java  servlets  and 
HTML.  The  servlets  respond  to  requests  from  the  LMS  client  and  are  responsible  for 
CMI  data  model  persistence,  serving  the  student  course  and  lesson  menus,  and  launching 
the  selected  lesson. 
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The  purpose  of  this  course  is  to  demonstrate  the  functionality  and 
capability  of  the  ADL  SAMPLE  LMS.  CTC  does  not  recommend, 
propose  or  otherwise  promote  the  style,  fashion,  or  type  of  content 
presented  in  this  course. 

Inland  Rules  of  the  Road 


REFERENCE:  U  S.  Coast  Guard,  Commandant  Instruction  Ml 6672. 2C 


The  material  of  this  course  is  of  the  U.S  Coast  Guard's  Rules  of  the  Road  in 
compliance  with  U.S.  Regulations. 


JSlxli 


: : LMSIni tialize  3] 

Trying  to  get  core  data  from  servlet. . . 

In  ServletProxy: : GetCMICoreDataf ) 

The  cmiCoreData  Object  for  the  current  AU  contains  the  folloi>j 
student_id:  UserOl 
student_name:  Joe  Student 
lesson_location: 
credit:  credit 

slesson_status:  not  attempted 
entry:  ab-initio 
score. raw 
score. min 
score. max 
time :  0 : 0 : 0 . 0 
lesson_mode:  normal 
In  API: :LMSGetValue 

Looking  for  the  element  cmi. core. lesson_status 
Returning  not  attempted 
In  API : : LMSGetLastEr ror ( ) 

In  API: : LMSSetValue ( ) 

Looking  for  the  element  cmi. core. lesson_status 
Set  cmi. core. lesson_status  to  incomplete 


<E:  This  course  will  give  the  student  a  basic 
and  Rules  of  Navigation.  These  rules  have  been 
according  to  the  instruction  listed  above  and  U.S. 


Figure  8-2.  LMS  Server  Functionality 


SCORM  (1.0) 


Page  94 


ADL  Sharable  Courseware  Object  Reference  Model 


There  are  five  servlets,  as  described  below: 

1.  LMS  CMIServlet. j  ava.  The  LMSCMIServletprovides  a  mechanism  for 
communication  between  the  LMS  and  the  assignable  unit — in  this  case  the  lesson. 
This  particular  implementation  is  specifically  for  the  CMI  data  model  described  in 
the  SCORM.  Other  modules  could  be  created  to  handle  other  data  models  as  they 
come  into  existence.  This  servlet  sends  and  receives  serialized  data  model  objects 
via  HTTP  to  and  from  the  LMS  API  client  (see  Section  8.1.2).  This  sample 
supports  only  the  core  data  elements  defined  in  Appendix  B  of  the  AICC  CMI 
Guidelines  for  Interoperability ,  Version  3.0.  Data  persistence  is  handled  by 
Java’s  built-in  serialization  mechanism  using  a  file  on  the  local  file  system.  No 
database  systems  are  being  used  at  this  time. 

2.  LMSLoginServlet.java.  The  LMS LoginS ervlet  provides  the  ability  to  validate 
the  student  and  serve  the  student’s  course  menu.  The  course  menu  is  an  HTML 
page  dynamically  built  by  the  servlet.  This  servlet  is  expandable  to  allow  for 
future  dynamic  generation  of  course  menus  based  on  student  course  registration. 

It  is  invoked  from  the  LMS  client  when  the  user  presses  “submit”  on  the  LMS 
Login  form. 

3.  LMSCourseServlet.java.  The  LMSCourseServlet  provides  the  ability  to  serve 
the  course  lesson  menu.  Similar  to  the  student  course  menu,  the  course  lesson 
menu  is  an  HTML  page  that  is  dynamically  built  by  the  servlet.  This  servlet  is 
also  expandable  to  allow  for  dynamic  lesson  menu  generation  based  on  a  CSF 
XML  document  in  a  future  release.  This  servlet  is  called  when  the  student  clicks 
on  the  course. 

4.  LMSLessonServletjava.  The  LMSLessonServlet  provides  the  ability  to  launch 
the  assignable  units  for  the  lesson.  The  servlet  also  handles  the  sequencing  of  the 
assignable  units.  In  this  version,  the  sequencing  is  hard  coded  and  not  based  on  a 
CSF.  This  servlet  serves  the  appropriate  assignable  unit  page  of  the  selected 
lesson  to  the  browser  within  the  LMS  client  framework.  It  is  called  when  the  user 
navigates  through  the  lesson. 

5.  LMSResetDB Servlet. java.  The  LMSResetDBServlet  provides  the  ability  to 
delete  the  student-persistent  data  that  the  LMS  maintains.  This  action  will  reset 
the  student  back  to  the  “not  have  entered  the  lesson  yet”  state.  This  is  provided  as 
a  convenience  to  the  user  so  that  the  student  data  does  not  have  to  be  deleted 
manually  at  the  server.  This  capability  is  necessary  if  you  want  to  use  the  sample 
lesson  multiple  times.  Because  the  LMS  tracks  lesson  completion  and  does  not 
allow  students  to  take  the  lesson  multiple  times,  it  is  necessary  to  delete  the 
student  data  and  reset  the  state  of  the  sample  lesson. 

8.1.2  LMS  Client 

The  LMS  client  side  consists  of  an  LMS  sample  user  interface  implemented  in  HTML 
and  JavaScript  and  the  LMS  API  implemented  as  a  Java  applet  (see  Figure  8-3).  The 
applet  is  downloaded  to  the  client  when  the  user  accesses  the  LMS  Main  start  page 
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Figure  8-3.  LMS  Client 

through  a  Web  browser.  The  API  applet  provides  the  communication  to  the  LMS  server 
for  data  model  element  persistence.  The  assignable  units  make  calls  to  the  API  functions 
from  JavaScript.  (See  the  description  of  the  sample  course  below  for  a  description  of 
how  the  LMS  API  function  calls  are  made  from  the  assignable  units).  The  assignable 
units  do  not  need  to  know  about  any  of  the  LMS  implementation  details. 

The  following  java  source  files  make  up  the  client  side  LMS  API  implementation: 

•  API.java.  This  file  contains  the  API  class  that  is  extended  from  the  Java  Abstract 
Window  Toolkit  (AWT)  applet  class  and  implements  the  LMS  API  functions  (i.e., 
LMSInitialize,  LMSFinish,  and  so  forth). 

•  LMSErrorManager.java.  This  file  contains  the  LMSErrorManager  class,  which 
encapsulates  the  error-handling  capabilities  specified  for  the  LMS  API.  It 
maintains  the  most  recent  error  code  and  the  mapping  of  error  codes  to  the  error 
text  and  diagnostic  information. 

•  ServletProxy.java.  This  file  contains  the  ServletProxy  class,  which  encapsulates 
the  communication  between  the  LMS  client  API  applet  and  the  LMS  server. 

•  Servlet Writer  .java.  This  file  contains  the  ServletWriter  class,  which  provides 
the  low-level  input  and  output  serialized  object  streaming  capability  used  by 
ServletProxy  to  communicate  with  the  servlet(s)  via  HTTP.  This  class  was 
downloaded  from  http://www.iavasoft.com. 

The  HTML/ JavaScript  sample  LMS  User  Interface  is  made  up  of  the  following  HTML 
files: 

•  LMSMain.htm.  This  file  is  the  main  LMS  client  page  in  which  all  student  access 
must  begin.  This  page  contains  a  frameset,  which,  in  turn,  contains  two  frames: 
an  LMS  navigation  frame  (left-side),  which  loads  the  LMSFrame.htm  and  a 
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content  frame  (right-side).  The  content  frame  initially  contains  the  start  page  (see 
LMSStart.htm).  As  the  user  logs  in  and  selects  a  course,  lesson,  and  so  forth,  the 
right-side  frame  houses  this  content.  Currently,  no  internal  checks  exist  to 
prevent  the  user  from  typing  in  the  URL  of  one  of  the  other  LMS  HTML  pages 
before  starting  at  LMSMain.htm.  If  the  user  attempts  to  access  one  of  the  other 
pages,  undetermined  LMS  behavior  will  result. 

•  LMSFrame.htm.  This  page  contains  the  LMS  API  applet.  The  LMS  API  applet 
has  no  visual  display  elements  and  is  therefore  invisible  to  the  user.  The 
assignable  units  communicate  with  the  LMS  via  this  API.  This  page  also  contains 
a  login  and  logout  button. 

•  LMSStarthtm.  This  page  contains  a  brief  textual  description  of  the  ADL 
Sample  LMS.  It  is  initially  displayed  in  the  right  frame  of  the  LMSMain.htm 
page  when  the  user  first  accesses  the  sample  LMS. 

•  LMSLogin.htm.  This  page  contains  an  HTML  form  that  prompts  the  user  for  a 
user  name  and  password.  Currently,  no  checks  are  performed  on  the  entries  on 
this  form,  and  the  user  may  proceed  simply  by  clicking  the  “Submit”  button. 
Submitting  this  form  invokes  the  LMSLoginServlet. 

•  LMSResetConfirm.htm.  This  page  displays  an  “Are  You  Sure?”  message  to  the 
user  when  they  choose  Reset  Student  from  the  main  LMS  client  page. 

•  LMSResetComplete.htm.  This  page  displays  a  “Reset  Complete”  message  to 
the  user  when  the  student  data  have  been  deleted. 

8.1 .3  AICC  CMI  Data  Model 

As  mentioned  previously,  the  AICC  CMI  data  model  (see  Figure  8-4)  is  the  data  model 
used  to  communicate  between  the  LMS  and  the  assignable  units  and  vice  versa.  At  this 
time,  only  the  core  data  elements  are  implemented  in  this  sample. 

Several  classes  are  included  to  represent  the  core  data  elements  of  the  CMI  model.  Both 
the  servlets  and  the  applet  use  these  classes.  Eventually,  each  data  type  described  in  the 
AICC  CMI  guidelines  will  be  implemented  as  its  own  class.  At  this  time,  only  the 
CMITime  data  type  is  implemented  as  a  java  class. 

The  source  for  these  classes  is  as  follows: 

•  CMIScoreData.java.  The  CMISScoreData  contains  the  implementation  for 
cmi.core. score  data  element. 

•  CMITime.java.  The  CMITime  contains  the  implementation  of  the  CMITime 
data  type. 

•  CMICoreData.java.  The  CMICoreData  contains  the  implementation  of  the 
cmi.core  data  model  elements  needed  for  the  AU  to  LMS  and  LMS  to  AU 
communication. 
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1  3  ADL  Sample  LMS  -  Microsoft  Internet  Explorer 
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Figure  8-4.  AICC  CMI  Data  Model 


8.1.4  Sample  Course 

The  course  provided  with  this  sample  LMS  contains  one  lesson.  The  lesson  is  a  simple 
“page  turner”  written  in  HTML  and  JavaScript  and  consists  of  seven  assignable  units. 

The  lesson  is  not  meant  to  serve  as  “a  great  example  of  a  how  to  develop  learning 
content,”  but  rather  as  an  example  of  how  to  communicate  data  between  the  LMS  and  the 
assignable  units  using  the  API.  The  assignable  unit  HTML  pages  used  in  this  lesson 
make  use  of  two  JavaScript  “include”  files  called  APIWrapper.js  and  AUFunctions.js. 

The  APIWrapper.js  file  contains  a  set  of  “API  wrapper”  functions  that  encapsulate  the 
functionality  an  assignable  unit  might  use  to  communicate  with  the  LMS  via  the  API. 
This  file  does  not  implement  the  API  functions.  It  encapsulates  the  logic  needed  to: 

•  Find  the  API  in  the  LMS  client  framework 

•  Call  the  desired  API  function 

•  Handle  errors  that  might  be  generated  by  the  call  to  the  API  function. 

The  assignable  units  are  written  using  the  wrapper,  thus  providing  a  level  of  abstraction 
above  the  actual  implementation  of  the  API  and  hiding  the  functionality  of  the 
communication  between  the  client  and  the  server. 

The  lesson  assignable  units  consist  of  the  following  source  files: 

•  au01.htm,  au02.htm,  au03.htm,  au04.htm 

•  au05.htm,  au06.htm,  au07.htm. 
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The  AUFunctions.js  file  contains  a  set  of  navigation  functions  common  to  all  of  the 
assignable  units.  This  file  contains  JavaScript  functions  used  by  all  of  the  lesson  HTML 
pages.  It  is  included  at  runtime  in  each  of  the  above  HTML  pages.  (Something  similar  to 
this  might  be  provided  by  authoring  tools  to  encapsulate  general  functionality  commonly 
built  into  all  the  courses  authored  by  that  particular  tool.) 

8.1 .5  Mapping  Example  Code  to  the  SCORM 

Figure  8-5  shows  the  mapping  of  example  code  to  the  SCORM. 
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Figure  8-5.  Mapping  Example  Code  to  the  SCORM 


8.1.6  Structure  of  Sample  LMS  Application 

Figure  8-6  illustrates  the  relationship  of  the  SCORM  Sample  LMS  files. 
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Assignable 

Unit 


Figure  8-6.  The  Relationship  of  the  SCORM  Sample  LMS  Files 

8.1 .7  Flow  of  Sample  LMS  Application 

Figure  8-7  illustrates  the  flow  of  the  sample  SCORM  LMS  code: 
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1 .  API  adapter  loaded  5.  Lesson  Selection  8.  LMS  tracks 

Data  using  “gets” 
and  “sets”  issued 
from  the  AU 


Figure  8-7.  The  Flow  of  the  Sample  SCORM  LMS  Code 

8.1 .8  API  Wrapper  JavaScript  Code  Fragment 

The  following  code  fragment  is  from  APIWrapper.js  in  the  SCORM  sample  LMS 
package.  This  code  is  used  on  the  client  side  to  locate  the  API  and  to  call  the  API  in  the 
applet  API. java. 

function  LMSInitialize() 

{ 

var  api  =  GetAPI(); 
if  (api  ==  null) 

{ 

alert(“Unable  to  locate  the  LMS’s  API  ImplementationAnLMSInitialize  was  not  successful.”); 
return  false; 

} 

//  call  the  LMSInitialize  function  that  should  be  implemented  by  the  API 
var  emptyString  =  new  String(““); 
var  initResult  =  api.LMSInitialize(emptyString); 
if  (initResult.toStringO  !=  “1”) 

{ 

//  LMSInitialize  did  not  complete  successfully, 
var  err  =  ErrorHandler(); 

i 

return  initResult; 

i 


function  LMSFinish() 

{ 

var  api  =  GetAPI(); 
if  (api  ==  null) 

{ 

alert(“Unable  to  locate  the  LMS’s  API  ImplementationAnLMSFinish  was  not  successful.”); 

} 

else 

{ 

api.LMSFinish(); 
var  err  =  ErrorHandler(); 

i 

return; 

i 

function  LMSGetValue(name) 

{  ...  } 

function  LMSSetVaIue(name,  value) 
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{  } 

function  LMSCommit() 

{  •••  } 

function  LMSGetLastError() 

{  •••  } 

function  LMSGetErrorString(errorCode) 

{  -  } 

function  LMSGetDiagnostic(errorCode) 

{  -  } 

function  LMSIsInitialized() 

{  -  } 

function  FindAPI() 

{ 

if(_Debug)  { alert(“in  FindAPI()”); } 

//Is  it  in  the  current  window? 
if  (window. document.  API  !=  null) 

{ 

if(_Debug){alert(“found  api  in  this  window”);} 
return  window. document. API; 

} 

//  Is  it  in  the  window’s  opener? 
if  (window. opener  !=  null) 

{ 

if  (_Debug)  {alert(“ window  opener  is  NOT  NULL”);} 

if  (window. opener.API  !=  null) 

{ 

if(_Debug){alert(“found  api  in  this  window’s  opener.”);} 
return  window. opener.API; 


else 

{ 

//  look  in  the  openers  window’s  frames... 
if  (window. opener.parent  !=  null) 

{ 

if  (_Debug)  {  alert(“looking  in  window  opener  parent’s  frames”);} 
for  (i=0;  i<window.opener.parent.frames. length;  i++) 

{ 

if  (window. opener.parent. frames. item(i). API  !=  null) 

{ 

if(_Debug){alert(“found  api  in  this  window’s  opener’s  parent’s  frames.”);} 
return  window. opener.parent.frames.item(i). API; 


//  Is  it  in  the  current  window’s  parent? 
if  (window. parent  !=  null) 

{ 

if  (window. parent. document.  API  !=  null) 

{ 

if(_Debug){alert(“found  api  in  this  window’s  parent.”);} 
return  window.parent.API; 

} 

else 

{ 

//  look  in  the  parent  window’s  frames... 

//  this  is  probably  the  most  likely  place  for  it  to  be... 
for  (i=0;  i<window.parent. frames. length;  i++) 

{ 

if  (window.parent.frames.item(i).API  !=  null) 

{ 

if(_Debug) { alert(“found  api  in  this  window’s  parents  frames.”);} 
return  window.parent.frames.item(i).API; 


SCORM  (1.0) 


Page  102 


ADL  Sharable  Courseware  Object  Reference  Model 


I 

//  The  API  was  not  found 
if  (_Debug) 

I 

alert(“couldn't  find  an  API  implementation”!; 

I 

return  null; 


function  GetAPI() 

{ 

return  apiHandle; 

) 


8.1.9  Course  Structure  Format  XML  Fragment 

<?xml  ver sion="l . 0"?> 

<!--File  Name:  MaritimeNavigation . xml — > 

< ! DOCTYPE  course  SYSTEM  "scocsf  (1 . 0 )  . dtd"> 

<! — This  is  an  example  of  a  course — > 

<course> 

<globalProperties> 

<externalMetadata> 

<source>IEEE  3.0</source> 

<model>IMSBP</model> 

<location>\metadata\Mar itiemNavigation . xml</locat ion> 

</externalMetadata> 

</ globalProperties> 

<block  id="Bl"> 

<ob jectiveRef  targetIDs="01"></ ob jectiveRef > 

<identif ication> 

<title>Maritime  Navigat ion</title> 

<labels> 

<curricular>UNIT</ curricular> 

</labels> 

</ identif ication> 

<extensions> 

<source>AICC  CMI  AGR-00 6</source> 

<model>cmi</model> 

<property> 

<name>dif  f iculty</ name> 

<value>easy</value> 

</property> 

</ extensions> 

<block  id="B2"> 

<ob jectiveRef  targetIDs="02"></ ob jectiveRef > 

< identif icat ion> 

<title>Inland  Rules  of  the  Road</title> 

<labels> 

<curricular>MODULE</curricular> 

</labels> 

</ identif ication> 

<extensions> 

<source>AICC  CMI  AGR-00 6</source> 

<model>cmi</model> 

<property> 

<name>dif f iculty</name> 

<value>easy</value> 

</property> 

</ extensions> 

<au  id="Al"> 

<ob jectiveRef  target  IDs="03"x/ob  jectiveRef  > 

< identif icat ion> 

<t itle>Ref erences</title> 

</ identif icat ion> 

<launch> 

<location>http : //&#60; host&#62; /Courses /Course 01/Lesson01/ auOl . html</location> 

</launch> 

</au> 
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<block  id="B3"> 

<ob jectiveRef  target  IDs="04"x/ob jectiveRef > 

<identif ication> 

<title>Steering  &#38;  Sailing  Rules</tit le> 

<labels> 

<curricular>MODULE</ curricular> 

</labels> 

</ i dent if icat ion> 

<au  id="A2"> 

<externalMetadata> 

<source>IMSBP</ source > 

<model>IEEE  3.0</model> 

<location>\metadata\au02MetaData . xml</location> 

</ externalMetadata> 

<ob  jectiveRef  t  ar  get  I  Ds="05"x/ob  jectiveRef  > 

<ident if ication> 

<title>Conduct  of  Vessels  in  any  Condition  of 

Visibility</title> 

<labels> 

<curricular>LEARNING  STEP</curricular> 

</labels> 

</ identif ication> 

<launch> 

<location>http : //&#60; hosts# 62 ; /Courses /Course 01/Lesson01/ au02 . html</location> 
</launch> 

</au> 


8.1.10  Course  Metadata  XML  Example 

<?xml  version=“  1 .0”  encoding=“UTF-8”?> 

<!— DOCTYPE  RECORD  SYSTEM  ‘•http://www.imspioject.org/xmyiMS-MD01.dtd”  ~> 
<!—  Uses  Master  DTD  at  IMS  site.  — > 

<! DOCTYPE  RECORD  SYSTEM  “IMS-MDOl.dtd”  > 

<!—  If  used  with  a  local  DTD,  use  this  DOCTYPE  declaration  instead  of  Master  above.  — > 


<RECORD  xmlns=“http://www. imsproject.org/metadata/”> 

<METAMETADATA> 

<MET  AD  AT  ASCHEME> 

LOM-3.8 

</METADATASCHEME> 

</METAMETADATA> 

<GENERAL> 

<TITLE> 

<LANGSTRING>Inland  Rules  of  the  Road</LANGSTRING> 

</TITLE> 

<CATALOGENTRY> 

<CATALOGUE>ADL  Course  Catalogue  ID</CATALOGUE> 

<ENTRY> 

<LANGSTRING>1000</LANGSTRING> 

</ENTRY> 

</CATALOGENTRY> 

<CATALOGENTRY> 

<CATALOGUE>Course  Configuration  Management  System  Path</CATALOGUE> 
<ENTRY> 

<LANGSTRING>VOB:/vob/adli/source/SampleLMS/Courses/Course01/</LANGSTRING> 

</ENTRY> 

</CATALOGENTRY  > 

<CATALOGENTRY> 

<CATALOGUE>U.S.  Coast  Guard,  Commandant  Instruction</CATALOGUE> 

<ENTRY> 

<LANGSTRING>M6672.2C</LANGSTRING> 

</ENTRY> 

</CATALOGENTRY> 

<LANGUAGE>en-US</LANGUAGE> 

<DESCRIPTION> 
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<LANGSTRING>Basic  instruction  on  U.S.  Coast  Guard  and  U.S.  Regulation  of  Inland  Vessel  Rules  of 
Navigation</LANGSTRING> 

</DESCRIPTION> 

<KEYWORDS> 

<LANGSTRING>Vessel</LANGSTRING> 

<LANGSTRING>Inland  Navigation</LANGSTRING> 

<LANGSTRING>Coast  Guard</LANGSTRING> 

</KEYWORDS> 

</GENERAL> 

<LIFECYCLE> 

<VERSION> 

<LANGSTRING>1 .0</LANGSTRING> 

</VERSION> 

<STATUS> 

<LANGSTRING>Final</LANGSTRING> 

</STATUS> 

<CONTRIBUTE> 

<ROLE> 

<LANGSTRING>  Author  </LANGSTRING> 

</ROLE> 

<CENTITY> 

<VCARD> 

BEGIN:  VCARD 

ORG:Concurrent  Technologies  Corporation;ADLI  Project 
END:VCARD 
</VCARD> 

•c/CENT  ITY> 

<DATE> 

<DATETIME> 

2000-01-28 

</DATETIME> 

</DATE> 

</CONTRIBUTE> 

</LIFECYCLE> 

<TECHNICAL> 

<FORMAT> 

<LANGSTRING>text/html</LANGSTRING> 

</FORMAT> 

<LOCATION  type=“URF’> 

/Courses/CourseOl/ 

</LOCATION> 

<REQUIREMENTS> 

<TYPE> 

<LANGSTRING>Browser</LANGSTRING> 

</TYPE> 

<NAME> 

<LANGSTRING>Microsoft  Internet  Explorer</LANGSTRING> 

</NAME> 

<MINIMUMVERSION>5.0</MINIMUMVERSION> 

</REQUIREMENTS> 

</TECHNICAL> 

<EDUCATIONAL> 

<LEARNINGRESOURCETYPE> 

<LANGSTRING>Narrative  Text</LANGSTRING> 

</LEARNINGRESOURCETYPE> 

</EDUCATIONAL> 

<RIGHTS> 

<COST> 

<!—  yes  or  no  — > 

<LANGSTRING>no</LANGSTRING> 

</COST> 

<COPYRIGHTOROTHERRESTRICTIONS> 

<!—  yes  or  no  — > 

<LANGSTRING>no</LANGSTRING> 

</COPYRIGHTOROTHERRESTRICTIONS> 

<DESCRIPTION> 
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<LANGSTRING>Provided  as-is;  only  to  be  used  as  an  example. </LANGSTRING> 
</DESCRIPTION> 

</RIGHTS> 

<CLASSIFICATION> 

<PURPOSE> 

<LANGSTRING>Educational  Objective</LANGSTRING> 

</PURPOSE> 

<DESCRIPTION> 

<LANGSTRING>This  course  will  give  the  student  a  basic  understanding  of  the  Inland  Rules  of 
Navigation.</LANGSTRING> 

</DESCRIPTION> 

<KEYWORDS> 

<LANGSTRING>Inland  Navigation</LANGSTRING> 

</KEYWORDS> 

</CLASSIFICATION> 

</RECORD> 


8.1.11  Assignable  Unit  (Content)  Metadata  XML  Example 

<?xml  version=“  1 .0”  encoding=“UTF-8”?> 

<!— DOCTYPE  RECORD  SYSTEM  ‘•http://www.imsproject.org/xmyiMS-MD01.dtd”  -> 
<!—  Uses  Master  DTD  at  IMS  site.  — > 

<! DOCTYPE  RECORD  SYSTEM  ‘TMS-MDOl.dtd”  > 

<!—  If  used  with  a  local  DTD,  use  this  DOCTYPE  declaration  instead  of  Master  above.  — > 


<RECORD  xmlns=“http://www. imsproject.org/metadata/”> 

<METAMETADATA> 

<MET  AD  AT  AS  CHEME> 

LOM-3.8 

</METADATASCHEME> 

<LANGUAGE>en-US</LANGUAGE> 

</METAMETADATA> 

<GENERAL> 

<TITLE> 

<LANGSTRING>Conduct  of  Vessels  in  any  Condition  of  Visibility</LANGSTRING> 

</TITLE> 

<CATALOGENTRY> 

<CATALOGUE>ADL  Course  Catalogue  ID</CATALOGUE> 

<ENTRY> 

<LANGSTRING>1000-02</LANGSTRING> 

</ENTRY> 

</CATALOGENTRY> 

<CATALOGENTRY> 

<CATALOGUE>Course  Configuration  Management  System  Path</CATALOGUE> 

<ENTRY> 

<LANGSTRING>VOB:/vob/adli/source/SampleLMS/Courses/Course01/Lesson01/AU01</LANGSTRING> 

</ENTRY> 

</CATALOGENTRY> 

<LANGUAGE>en-US</LANGUAGE> 

<DESCRIPTION> 

<LANGSTRING>Discusses  general  rules  of  operation  for  vessels  on  inland  waters. 

Topics  discussed  include:  Look-out,  Safe  Speed,  Collision,  Channels,  Traffic  Separation. </LANGSTRING> 
</DESCRIPTION> 

<KEYWORDS> 

<LANGSTRING>Vessel</LANGSTRING> 

<LANGSTRING>Any  Visibility</LANGSTRING> 

<LANGSTRING>Look-out</LANGSTRING> 

<LANGSTRING>Safe  Speed</LANGSTRING> 

<LANGSTRING>Collision</LANGSTRING> 

<LANGSTRING>Channels</LANGSTRING> 

<LANGSTRING>TrafficSeparation</LANGSTRING> 

</KEYWORDS> 

<AGGREGATIONLEVEL>  1  </AGGREGATIONLEVEL> 

</GENERAL> 

<LIFECY  CLE> 

<VERSION> 
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<LANGSTRING>1 .0</LANGSTRING> 

</VERSION> 

<STATUS> 

<LANGSTRING>Final</LANGSTRING> 

</STATUS> 

<CONTRIBUTE> 

<ROLE> 

<LANGSTRING>  Author  </LANGSTRING> 

</ROLE> 

<CENTITY> 

<!—  Stub  of  a  vCard  entry  with  Formatted  Name  (FN)  property  — > 
<VCARD> 

BEGIN:VCARD 

ORG:Concun'ent  Technologies  Corporation;  ADLI  Project 
END:VCARD 
</VCARD> 

</CENTITY> 

<DATE> 

<DATETIME> 

2000-01-28 

</DATETIME> 

</DATE> 

</CONTRIBUTE> 

</LIFECYCLE> 

<TECHNICAL> 

<FORMAT> 

<LANGSTRING>text/html</LANGSTRING> 

</FORMAT> 

<SIZE> 

14368 

</SIZE> 

<LOCATION  type=“URI”> 
au02.htm 
</LOCATION> 

<!— type  of  URI  or  TEXT~> 

<REQUIREMENTS> 

<TYPE> 

<LANGSTRING>Browser</LANGSTRING> 

</TYPE> 

<NAME> 

<LANGSTRING>Microsoft  Internet  Explorer</LANGSTRING> 
</NAME> 

<MINIMUMVERSION>5.0</MINIMUMVERSION> 

</REQUIREMENTS> 

</TECHNICAL> 

<EDUCATIONAL> 

<FEARNINGRESOURCETYPE> 

<LANGSTRING>NaiTative  Text</LANGSTRING> 
</LEARNINGRESOURCETYPE> 

<TYPIG  AT  .1  ,F.ARNTNOTTMF.> 

<DATETIME> 

0000-00-00700:05 :00 
</DATETIME> 

</TYPICALLEARNINGTIME> 

</EDUCATIONAL> 

<RIGHTS> 

<COST> 

<!—  yes  or  no  — > 

<LANGSTRING>no</LANGSTRING> 

</COST> 

<COPYRIGHTOROTHERRESTRICTIONS> 

<!—  yes  or  no  — > 

<LANGSTRING>no</LANGSTRING> 

</COPYRIGHTOROTHERRESTRICTIONS> 

</RIGHTS> 

<CLASSIFICATION> 
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<PURPOSE> 

<LANGSTRING>Educational  Objective</LANGSTRING> 
</PURPOSE> 

<DESCRIPTION> 

<LANGSTRING> Vessel  Conduct</LANGSTRING> 
</DESCRIPTION> 

<KEYWORDS> 

<LANGSTRING> Vessel  Conduct</LANGSTRING> 
</KEYWORDS> 

</CLASSIFICATION> 

</RECORD> 


8.1.12  Raw  Media  Metadata  XML  Example 

<?xml  version=”  1 .0”  encoding=“UTF-8”?> 

<!— DOCTYPE  RECORD  SYSTEM  ‘•http://www.imsproject.org/xmyiMS-MD01.dtd”  ~> 
<!—  Uses  Master  DTD  at  IMS  site.  — > 

<! DOCTYPE  RECORD  SYSTEM  “IMS-MDOl.dtd”  > 

<!—  If  used  with  a  local  DTD,  use  this  DOCTYPE  declaration  instead  of  Master  above.  — > 


<RECORD  xmlns=“http://www. imsproject.org/metadata/”> 

<METAMETADATA> 

<MET  AD  AT  AS  CHEME> 

LOM-3.8 

</METADATASCHEME> 

<LANGUAGE>en-US</LANGUAGE> 

</METAMETADATA> 

<GENERAL> 

<TITLE> 

<LANGSTRING> Vessel  Aground  Lighting</LANGSTRING> 

</TITLE> 

<DESCRIPTION> 

<LANGSTRING> 

Picture  showing  lighting  requirements  for  inland  vessel  less  than  50  meters  in  length  in  an  aground  condition. 
</LANGSTRING> 

</DESCRIPTION> 

<KEYWORDS> 

<LANGSTRING>Vessel</LANGSTRING> 

<LANGSTRING>Lighting</LANGSTRING> 

<LANGSTRING>Aground</LANGSTRING> 

</KEYWORDS> 

</GENERAL> 

<LIFECYCLE> 

<VERSION> 

<LANGSTRING>1 .0</LANGSTRING> 

</VERSION> 

<STATUS> 

<LANGSTRING>Final</LANGSTRING> 

</STATUS> 

<CONTRIBUTE> 

<ROLE> 

<LANGSTRING>  Author  </LANGSTRING> 

</ROLE> 

<CENTITY> 

<!—  Stub  of  a  vCard  entry  with  Formatted  Name  (FN)  property  — > 

<VCARD> 

BEGIN:VCARD 

ORG:Concurrent  Technologies  Corporation;  ADLI  Project 
END:VCARD 
</VCARD> 

</CENTITY> 

<DATE> 

<DATETIME> 

2000-01-28 

</DATETIME> 

</DATE> 

</CONTRIBUTE> 
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</LIFECYCLE> 

<TECHNICAL> 

<FORMAT> 

<LANGSTRING>image/jpeg</LANGSTRING> 

</FORMAT> 

<SIZE> 

10612 

</SIZE> 

<LOCATION  type=“URI”> 
aground.jpg 
</LOCATION> 

<!— type  of  URI  or  TEXT-> 

</TECHNICAL> 

<EDUCATIONAL> 

<LEARNINGRESOURCETYPE> 

<LANGSTRING>Figure</LANGSTRING> 

</LEARNINGRESOURCETYPE> 

</EDUCATIONAL> 

<RIGHTS> 

<COST> 

<!—  yes  or  no  — > 

<LANGSTRING>no</LANGSTRING> 

</COST> 

<COPYRIGHTOROTHERRESTRICTIONS> 

<!—  yes  or  no  — > 

<LANGSTRING>no</LANGSTRING> 

</COPYRIGHTOROTHERRESTRICTIONS> 

</RIGHTS> 

</RECORD> 


8.2  CSF  Browser/Editor 


The  CSF  Browser/Editor  (see  Figure  8-8)  is  a  java  application  that  can  create,  edit, 
display,  and  write  CSF  XML  files.  It  runs  on  top  of  the  IBM  XML  Lor  Java  Parser  using 
the  Simple  API  for  XML  driver  available  from  IBM’s  AlphaWorks  at 
http  ://w  ww  .alphaworks  .ibm.com/formula/XML. 

Note:  As  of  the  release  of  this  document,  the  CSLBrowser  is  “alpha”  code.  Soon  after 
the  release  of  this  document,  the  application  and  source  code  will  be  available  on  the 
ADL  web  site  (http : //ww  w . adlnet .  or g) . 


8.2.1  Overview  of  CSF  Browser/Editor 

This  tool  was  designed  principally  to  exercise  all  the  aspects  of  the  CSL  specification.  It 
parses  an  XML  CSL  file  and  displays  the  file’s  “original”  XML  structure.  Then,  it  maps 
each  element  into  a  Java  “data  model”  using  a  separate  course  tree.  The  course  structure 
tree  can  be  edited  and  written  back  out  as  XML.  Thus,  this  utility  tests  the  CSL  through 
the  input,  display,  and  output  translations  of  CSL  data. 

The  CSL  Browser  reads  XML  CSL  files  and  validates  them  against  the  DTD  specified  in 
the  XML  record.  The  application  has  four  view  panes: 

1.  XML  Representation  of  Course  Structure  pane.  This  pane  displays  in  a  tree 
format  each  of  the  XML  elements  exactly  as  they  were  parsed  when  a  CSL  XML 
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Figure  8-8.  Sample  ADL  CSF  Format  Browser 

file  is  opened.  Parsing  errors  during  loading  are  displayed  in  the  Information 
pane.  This  tool  makes  viewing  the  contents  of  a  CSF  XML  file  easier  than 
reading  the  raw  code.  The  XML  Representation  pane  cannot  be  edited  and  only 
displays  initially  loaded  files. 

2.  ADL  Course  Structure  pane.  This  pane  contains  another  tree  similar  to  the 
XML  Representation  pane,  except  that  it  only  shows  course,  globalProperties, 
block,  au,  and  objectives  in  the  tree.  This  makes  viewing  the  course  structure 
easier. 

The  Course  Structure  tree  can  be  edited.  Clicking  on  course,  globalProperties, 
block,  au,  or  objectives  brings  up  an  editor  for  each  of  the  elements  of  these 
groups.  Nodes  in  the  tree  can  be  added,  deleted,  or  moved. 

3.  Information  pane.  This  pane  displays  guidance  information  about  items  selected 
and  displays  relevant  text  messages  or  outputs  when  selected. 

4.  Editor  pane.  This  pane  displays  the  elements  of  course,  globalProperties,  block, 
au,  or  objectives  tree  nodes  when  they  are  selected. 

After  editing,  CSF  trees  may  be  saved  as  CSF  XML  files  or  displayed  in  the  Information 
Pane. 
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9.  Acronym  List 


ADL 

Advanced  Distributed  Learning  [Initiative] 

ADL-CoLab 

ADL  Collaboration  Laboratory 

AICC 

Aviation  Industry  CBT  Committee 

API 

Application  Programming  Interface 

AU,  au 

Assignable  Unit 

AWT 

Abstract  Window  Toolkit 

CBI 

Computer-Based  Insturction 

CMI 

Computer-Managed  Instruction 

CSF 

Course  Structure  Format 

DC 

Dublin  Core 

DoD 

Department  of  Defense 

DTD 

Document  Type  Definition 

HTML 

Hypertext  Markup  Language 

IEEE 

Institute  of  Electrical  and  Electronics  Engineers 

IMS 

Instructional  Management  Systems  [Project] 

ISO 

International  Standards  Organization 

JPEG 

Joint  Photographic  Experts  Group 

LMS 

Learning  Management  System 

LOM 

Learning  Object  Metadata 

LTSC 

Learning  Technology  Standards  Committee 

OSTP 

Office  of  Science  and  Technology  Policy 

SCO 

Sharable  Courseware  Object 

SCORM 

Sharable  Courseware  Object  Reference  Model 

SEL 

Standard  Extension  Library 

URI 

Universal  Resource  Identifier 

URL 

Universal  Resource  Locator 

XML 

Extensible  Markup  Language 
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Appendix  A  -  Supporting  Documents 


A.  1  SCORM  Course  Structure  Format  DTD 


<i — ***  scormcsf (1 . 0) . dtd 

***  course:  Root  level  of  Course  Structure  representation — > 

<! ELEMENT  course  (giobalProperties?, block, objectives?)  > 

<i — ***  giobalProperties :  Properties  of  the  course  as  whole — > 

<! ELEMENT  giobalProperties  (externalMetadata+, curricularTaxonomy? , extensions*)  > 

<i — ***  block:  A  grouping  of  related  structural  elements. 

Blocks  contain  assignable  units  or  other  blocks. 

Blocks  always  contain  other  course  elements . 

This  holds  an  unique  (to  this  course)  ID  identifier 
for  a  particular  block. 

ID's  are  generated  by  the  application  (e.g.,  an  LMS) 
that  creates  a  CSF  XML  file 

(other  elements  may  refer  to  this  unique  ID) — > 

<! ELEMENT  block  ( (externalMetadata* , object iveRef* , identification , prerequisites? , 
completionReq?, extensions*, (au*  |  block*) +)  |  blockAlias)  > 

< ! ATTLIST  block 

id  ID  # REQUIRED  > 

<i — ***  objectives:  Root  level  of  objectives  tree; 

Statements  of  skills,  knowledge,  and  attitudes 
to  be  acquired  by  the  student . — > 

<! ELEMENT  objectives  (objective*)  > 

<i — ***  externalMetadata:  The  value  of  this  element  refers 
or  points  to  the  location  of  the  metadata 
describing  this  course. — > 

<! ELEMENT  externalMetadata  (source , model , location)  > 

<! — ***  curicularTaxonomy :  Organizational  methodology 
used  to  construct  the  course — > 

< ! ELEMENT  curricularTaxonomy  (source?, model, location?)  > 

<i — ***  extensions:  defines  extensions  to  course  element 
definitions  and  their  source — > 

<! ELEMENT  extensions  (source? , model , location? , property*)  > 

<i — **★  ob jectiveRef :  Reference  to  a  particular  objective 
in  the  objective  hierarchy — > 

<! ELEMENT  ob jectiveRef  EMPTY  > 

<! ATTLIST  object iveRef 

targetIDs  IDREFS  #IMPLIED  > 

<! — ***  identification:  Identifies  course  context- 
specific  information — > 

<! ELEMENT  identification  (title, description? , labels?)  > 

<i — **★  prerequisites:  Expression  indicating  what  a  student 
must  accomplish  before  beginning  this  course  element. 

Course  elements  that  a  student  must  complete  before  beginning 
a  block  or  assignable  unit.  It  uses  a  "script"  that  defines 
the  logical  rules  to  be  applied.  The  script  type  must  be  defined, 
e.g.,  prerequisites  type="aicc_script">  < ! [CDATA [B1&B2&A1 ] ] > 
</prerequisites>  — > 

<! ELEMENT  prerequisites  (#P CDATA)  > 
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<!ATTLIST  prerequisites 

type  CDATA  # IMPLIED  > 

<! — ***  completionReq:  Course  elements  that  a  student  must  complete 

before  considering  a  given  structure  element  complete.  It  uses 
a  "script"  that  defines  the  logical  rules  to  be  applied.  The 
script  type  must  be  defined,  e.g., 

<completion  type="aicc_script">  <! [CDATA [B1&B2&A1] ] >  </completion> — > 

< ! ELEMENT  completionReq  (#P CDATA)  > 

<! ATTLIST  completionReq 

type  CDATA  # IMPLIED  > 

<i — ***  au;  An  AU  is  the  smallest  element  of  instruction  or  testing  to 
which  a  student  may  be  routed  by  a  LMS .  It  refers  to  "content" 
launched  by  the  LMS  system. 

This  holds  a  unique  (to  this  course)  ID  identifier  for  a  particular 
au  ID's  are  generated  by  the  application  (e.g.,  an  LMS)  that  creates 
a  CSF  XML  file  (other  elements  may  refer  to  this  unique  ID) — > 

<! ELEMENT  au  ( (externalMetadata* , ob jectiveRef * , identification, prerequisites? , 
completionReq?, timeLimit?, launch? , masteryScore? , extensions*)  | 
auAlias)  > 

< ! ATTLIST  au 

id  ID  # REQUIRED  > 

<! — ***  blockAlias :  Reference  to  a  previously  defined  block 

(permits  one  block  to  be  used  more  than  once  within  a  course) — > 

<! ELEMENT  blockAlias  EMPTY  > 

<! ATTLIST  blockAlias 

targetID  ID  #IMPLIED  > 

<i — ***  objective:  A  statement  of  skills,  knowledge,  and  attitudes  to  be 
acquired  by  the  student.  This  holds  an  unique  (to  this  course)  ID 
identifier  for  a  particular  objective  ID's  are  generated  by  the 
application  (e.g.,  an  LMS)  that  creates  a  CSF  XML  file 
(other  elements  may  refer  to  this  unique  ID) — > 

<! ELEMENT  objective  ( (externalMetadata* , assignmentRef * , identification, 
prerequisites?, completionReq?, extensions*, objective*)  | 
ob jectiveAlias)  > 

<! ATTLIST  objective 

id  ID  # REQUIRED  > 

<i — **★  source:  Authority  or  source  of  data  model  w/reference  to  a  spec,  if  available 
e.g.,  "AICC  AGROIO  v3.4",  or  ARMY  TRADOC  specl23,  or  "IMSBP  v4.2" — > 

<! ELEMENT  source  (#PCDATA)  > 

<! — ***  model:  Name  of  a  specific  data  model  used  by  this  course 
e.g.,  "cmi",  or  "ARMY314",  or  "IMS  vl.O" — > 

<! ELEMENT  model  (#P CDATA)  > 

<! — ***  location:  URI  Location — > 

<! ELEMENT  location  (#P CDATA)  > 

<i — ***  property:  Name/value  pair  extension  for  this  course — > 

<! ELEMENT  property  (name, value)  > 

<i — **★  title:  Context  specific  title. 

May  be  used  by  an  LMS  system  in  menus,  screens,  etc. — > 

<! ELEMENT  title  (#P CDATA)  > 

<i — ***  description:  Context  specific  textual  information  about  the  course  element. 

It  may  contain  the  purpose,  scope,  or  summary.  (Defined  by  course  author) — > 

<! ELEMENT  description  (#P CDATA)  > 

<i — **★  labels:  Context  specific  local  label  (e.g.,  unit,  chapter, 
learning  step) — > 

<! ELEMENT  labels  (curricular? , developer?)  > 
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<i — ***  Time  values  or  actions  associated  with  this  au  in  this  context — > 

< ! ELEMENT  timeLimit  (maxTimeAl lowed? , timeLimitAction? )  > 

<! — ***launch:  Information  needed  by  an  LMS  to  launch  an  au — > 

< ! ELEMENT  launch  (location, parameterstring?, dataFromLMS?)  > 

<i — ***  score:  Values  to  be  used  in  this  course  context  for  tracking 
score  within  an  au — > 

<! ELEMENT  masteryScore  (#PCDATA)  > 

<i — ***  auAlias:  Reference  to  a  previously  defined  au 

(permits  one  au  to  be  used  more  than  once  within  a  course — > 

<! ELEMENT  auAlias  EMPTY  > 

< ! ATTLIST  auAlias 

targetID  ID  #IMPLIED  > 

<! — ***  assignmentRef :  Reference  to  a  particular  block  or  au  element 
in  the  course  structure  hierarchy  e.g., 

<assignmentRef  "targetIDs="Bl , A23"/> — > 

<! ELEMENT  assignmentRef  EMPTY  > 

<! ATTLIST  assignmentRef 

relation  CDATA  # IMPLIED 

targetIDs  IDREFS  #IMPLIED  > 

<! — ***  ob jectiveAlias :  Reference  to  a  previously  defined  objective 

(permits  one  objective  to  be  used  more  than  once  within  a  course) — > 
<! ELEMENT  ob jectiveAlias  EMPTY  > 

<! ATTLIST  ob jectiveAlias 

targetID  IDREF  #IMPLIED  > 

<i — ***  name:  Descriptive  name  of  a  course  property  extension 
e.g.,  "difficulty"  (as  in  degree  of) — > 

<! ELEMENT  name  (#PCDATA)  > 

<! — ***  value:  Value  associated  with  the  named  extension 
e.g.,  "easy" — > 

<! ELEMENT  value  (#P CDATA)  > 

<i — ★**  curricular  label:  Local  name  of  course  element 
e.g.,  "UNIT",  "MODULE",  "LEARNING  STEP" — > 

<! ELEMENT  curricular  (# PCDATA)  > 

<i — **★  developer  label:  an  organization-specific  identifier  (e.g.,  D509) — > 
<! ELEMENT  developer  (#P CDATA)  > 

<i — ★  **  maxTimeAl lowed:  The  amount  of  time  the  student  is  allowed 
to  have  in  the  current  attempt  on  the  lesson. — > 

<! ELEMENT  maxTimeAl lowed  (#PCDATA)  > 

<i — **★  timeLimitAction:  What  the  lesson  is  to  do  when  the  max  time 
allowed  is  exceeded.  AICC  examples:  "exit",  "continue", 

"message" ,  "continue" . — > 

<! ELEMENT  timeLimitAction  (#P CDATA)  > 

<i — ***  parameterstring:  String  of  characters  needed  to  successfully 
launch  a  content  au — > 

<! ELEMENT  parameterstring  ( #P CDATA)  > 

<i — **★  dataFromLMS:  unconstrained  (undefined)  initialization  data  expected 
by  content  when  it  is  launched  by  the  LMS. — > 

<! ELEMENT  dataFromLMS  (#P CDATA)  > 
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A.2  Course  Structure  Format  Mapping  to  AICC  Structure 


CSF  Element  Name 

AICC  Name 

Contextualized  Definition 

List 

Level 

Data  Type 

Global  Properties 

Properties 

Information  that  applies  to  the 
course  as  a  whole. 

S 

1 

G  lobalP  roperties.externalM  etadata 
(located  in  external  metadata  record) 

|— Creator 

Name  of  the  vendor  and/or 
author  of  the  course. 

* 

1 

CMIString256 

G  lobalP  roperties.externalM  etadata 
(located  in  external  metadata  record) 

-Identifier 

Unique  label  for  the  course. 

s 

1 

CMIIdentifier 

G  lobalP  roperties.externalM  etadata 
(located  in  external  metadata  record) 

|-System 

Predominant  authoring  system 
used  to  create  the  course. 

s 

1 

DString 

(Root)block.identification.  title 

G  lobalP  roperties.externalM  etadata 
(can  also  be  located  in  external 
metadata  record) 

|— Title 

Common  name  given  to  course. 

s 

1 

CMIString256 

G  lobalP  roperties.externalM  etadata 
(located  in  external  metadata  record) 

-Level 

Indicator  of  the  complexity  of 
structure  and  sequencing  data. 

s 

1 

CMIString256 

|— Max  Block 
Members 

Number  of  members  in  most 
populous  block. 

s 

1 

CM  llnteger 

|-Max  Objective 
Members 

Number  of  members  in  most 
populous  objectives  relationship. 

s 

1 

CMlInteger 

|— Total  AU's 

Total  number  of  unique 
assignable  units  in  the  course. 

s 

1 

CM  llnteger 

-Total  Blocks 

Total  number  of  blocks  in  the 
course. 

s 

1 

CMlInteger 

|— Total 

Objectives 

Total  number  of  objectives 
(simple  and  complex)  in  the 
course. 

s 

1 

CMlInteger 

|— Total  Complex 
Objectives 

Total  number  of  complex 
objectives  in  the  course. 

s 

1 

CMlInteger 

G  lobalP  roperties.externalM  etadata 
(located  in  external  metadata  record) 

-Version 

The  revision  number  of  the  IEEE 
CMI  Standard  on  which  the 
course  sequencing  data  is 
based. 

s 

1 

CMIString256 

(Root)block.identification. 

description 

G  lobalP  roperties.externalM  etadata 
(can  also  be  located  in  external 
metadata  record) 

|-Description 

Textual  information  about  the 
course. 

s 

1 

CMIString4096 

-Max  Normal 

The  maximum  number  of 
assignable  units  that  may  be 
taken  for  credit  and  incomplete. 

s 

3A 

CMlInteger 

(root)  block 

Structure 

Information  on  organization  and 
sequencing  of  the  course. 

s 

1 

- 

block 

|-Block 

A  grouping  of  related  structural 
elements. 

+ 

1 

- 

block,  identification. labels. developer 

|--  -Identifier 

Developer  created  unique  label 
for  block. 

s 

1 

CMIString256 

Block  id 

|—|— System 
Identifier 

Course  unique  identifier  created 
by  the  CMI  system. 

s 

1 

C  M  IS  Identifier 

Block.identification.title 

|- |-Title 

Commonly  used  name  for  the 
block. 

s 

1 

CMIString256 

Block,  identification. description 

|-|-Description 

Textual  summary  of  block's 
contents. 

s 

1 

CMIString4096 
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CSF  Element  Name 

AICC  Name 

Contextualized  Definition 

List 

Level 

Data  Type 

Block.pre  requisites 

|—|— Prerequisite 

Expression  identifying  what  a 
student  must  accomplish  before 
beginning  the  block. 

S 

2 

CMILogic 

Block.completionReq 

|--  -Completions 

What  a  student  must  do  to  gain  a 
specific  status  fora  block. 

+ 

2 

-- 

l-l-l- 

Requirement 

Expression  that  may  be 
evaluated  as  true  or  false. 

s 

CMILogic 

Status 

The  credit  given  to  a  student 
when  the  requirements 
expression  is  true. 

s 

2 

CM  IVocabulary 

— Next  AU 

Forced  assignmentwhen  status 
is  true. 

s 

2 

C  M  IS  Identifier 

|—|—|— Return  to 

Forced  assignment  after  leaving 
NextAU. 

s 

2 

C  M  IS  Identifier 

Au 

-Assignable 

Unit 

Information  relating  to  an 
assignable  unit. 

* 

1 

“ 

Au.  identification,  labels,  developer 

-  -Identifier 

Developer  created  unique  label 
for  the  assignable  unit. 

s 

1 

CMIString256 

Au.id 

|--  -System 
Identifier 

Course  unique  identifier  created 
by  the  CM  1  system. 

s 

1 

C  M  IS  Identifier 

Au.identification.title 

|-  |-Title 

Commonly  used  name  for  an 
assignable  unit,  block,  objective, 
or  complex  objective. 

s 

1 

CMIString256 

Au. identification. description 

|—[— Description 

Textual  summary  of  unit's 
contents. 

s 

1 

CMIString4096 

Au.  identification. label. curricular 
(in  most  cases) 

-  -Type 

Developer  defined  category  for 

AU. 

s 

1 

CMIString256 

Au. launch. parameterstring 

[-[-Launch  Line 

The  string  of  characters  needed 
to  successfully  launch  an 
executable  program. 

s 

1 

CMIString256 

Au. launch. location 

|-  -File  Name 

The  full  identifier  of  the  files 
containing  the  content  of  the 
lesson. 

+ 

1 

CMIString256 

|--  -Max  Score 

Largest  raw  score  that  can  be 
reported  by  the  lesson. 

s 

1 

CM  IDecimal 

Au.masteryScore 

|—|— Mastery 

Score 

The  minimum  raw  score  required 
for  the  student  to  pass  the 
lesson. 

s 

1 

CM  IDecimal 

Au.  timelimit.  maxTimeAllowed 

|—|— Max  Time 
Allowed 

Amount  of  time  permitted  for  a 
student's  single  use  of  a  lesson. 

s 

1 

CMITimespan 

Au.  timelimit.  timeLimitAction 

|— |— Time  Limit 
Action 

Whatthe  lesson  should  do  when 
the  max  time  allowed  is 
exceeded. 

s 

1 

CM  IVocabulary 

Au.externalM etadata  (located  in 
external  metadata  record) 

|—|— System 
Vendor 

Authoring  system  used  to  create 
the  lesson. 

s 

1 

CMIString256 

Au.  launch.  dataFromLMS 

|--  -Launch 

Data 

Unique  information  required  by 
the  lesson's  desiqn. 

s 

1 

CMIString4096 

Au. prerequisites 

-  -Prerequisite 

Expression  identifying  what  a 
student  must  accomplish  before 
beginning  the  assignable  unit. 

s 

2 

CMILogic 

-  -Completions 

What  a  student  must  do  to  gain  a 
specific  status  for  an  assignable 
unit. 

+ 

2 
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CSF  Element  Name 

AICC  Name 

Contextualized  Definition 

List 

Level 

Data  Type 

Au.completionReq 

l-l-l- 

Requirement 

Expression  that  may  be 
evaluated  as  true  or  false. 

S 

2 

CMILogic 

|-- 1—|— Status 

The  credit  given  to  a  student 
when  the  requirements 
expression  is  true. 

S 

2 

CM  IVocabulary 

|—|—|— Next  All 

Forced  assignmentwhen  status 
is  true. 

s 

2 

CM  IS  Identifier 

- 1—|— Return  to 

Forced  assignment  after  leaving 
NextAU. 

s 

2 

C  M  IS  Identifier 

Au.objectivesRef 

l-l-l- 

Embedded 

Objectives 

Objective  that  is  in  the 
assignable  unit. 

* 

2 

CM  IS  Identifier 

(Root)  objectives 

Objectives 

Measurable  learninq  qoal. 

* 

3B 

- 

Objective. identification. label, 
developer 

-Identifier 

Developer  assigned  unique  label 
for  objective. 

s 

3B 

CMIString256 

Objective  id 

|— System 

Identifier 

Course  unique  identifier  created 
by  the  CM  1  system. 

s 

3B 

C  M  IS  Identifier 

Objective. identification. title 

-Title 

Commonly  used  name  for  the 
objective. 

s 

3B 

CMIString256 

Objective. identification. description 

|— Description 

Textual  summary  of  the 
objective. 

s 

3B 

CMIString4096 

Objective.  assignmentRef 

|-Member  IDs 

CMI  assigned  unique  label  for 
each  course  element  in  the 
objective. 

* 

3B 

C  M  IS  Identifier 

Objective.  completionReq 

|— Completions 

What  a  student  must  do  to  gain  a 
specific  status  for  an  objective 

+ 

3B 

l-l- 

Requirement 

Expression  that  may  be 
evaluated  as  true  or  false. 

s 

3B 

CMILogic 

-  -Status 

The  credit  given  to  a  student 
when  the  requirements 
expression  is  true. 

s 

3B 

C  M  IVocabulary 
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Appendix  B  -  AICC  API  Specification 

This  appendix  is  excerpted  in  its  entirety  from  AICC  Document  No.  CMI001,  CMI 
Guidelines  for  Interoperability ,  Version  3.0.1  (www.aicc.org).  The  excerpted  portion 
that  follows  is  also  Section  B  in  the  AICC  document. 
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CMI  Guidelines 


B.l 


API 


B.1.1 


B.l. 2 


Appendix  B:  API-based  CMI  Communication 


Introduction 


This  appendix  describes  an  Application  Programming  Interface  ( API)  implementation 
for  the  AICC  Computer  Managed  Instruction  (CMI)  standards.  It  defines  an  API 
which  may  be  used  over  the  Web  by  learning  content  to  communicate  with  a  Learning 
Management  System  (LMS).  In  this  document  a  CMI  system  may  be  thought  of  as  a 
separate  management  system  or  a  subset  of  the  functionality  of  an  LMS . 


This  document  also  defines  a  mechanism  for  launching  content  that  enables  an  LMS  to 
“bind"  the  LMS  neutral  API  to  an  LMS  specific  data  transfer  mechanism. 


HTTP  Implementation 


Appendix  A  of  this  document,  defines  data  exchange  in  terms  of  HACP  (HTTP  AICC 
CMI  Protocol),  an  HTTP-based  protocol.  HACP  has  proven  successful  in  commercial 
products  and  in  large-scale  LMS  applications.  However,  the  average  content 
developer  finds  HACP  difficult  to  understand  and  some  LMS  applications  require 
protocols  other  than  HTTP. 
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Description 


Advantages 


This  API  standardizes  the  way  content  sends  and  receives  information.  It  assumes  that 
content  will  communicate  using  the  widely  supported  ECMAScript  calling 
conventions  5.  ECMAScript  was  selected  as  the  method  for  implementing  this  API 
since  nearly  all  browser  platforms  natively  support  it.  This  standard  defines  several 
calls,  the  data  in  these  calls,  and  the  format  of  that  data. 


The  figure  below  illustrates  what  is  standardized.  Note  that  the  communication  of  the 
ECMAScript  with  the  LMS  is  outside  the  scope  of  this  standard.  Implementations  of 
the  communications  of  the  JavaScript  object  with  the  LMS  may  vary  from  product  to 
product.” 


There  are  several  reasons  for  expanding  the  number  of  IEEE  implementations  to 
include  an  API  standard  in  addition  to  an  HTTP-based  standard. 


Generally  speaking,  an  API  is  more  abstract  and  implementation  neutral  than  an 
approach  based  on  a  specific  protocol  such  as  HTTP.  A  content  API  essentially 
“hides”  the  implementation  details  of  communication  with  an  LMS. 

Another  advantage  of  an  API  is  that  it  can  make  it  easier  for  the  content  developer  to 
understand  and  use  communication  with  the  LMS.  Another  advantage  is  the  ability  of 
a  single  API  to  work  with  several  different  data  models.  And  finally,  an  API  enables 
learning  content,  without  being  changed,  to  work  with  different  data  transfer 
mechanisms. 


The  approach  defined  in  this  document  simplifies  the  creation  of  CMI  compliant 
content  by  allowing  content  developers  to  think  in  terms  of  a  higher-level  API.  This 
document  also  defines  how  to  support  the  AICC  and  IEEE  CMI  data  models. 
Although  designed  to  support  the  CMI  data  model,  the  API  defines  a  generic 
capability  that  can  be  applied  to  related  data  models  as  these  are  standardized. 

Content  using  the  API  can  be  reused  without  modification  with  different  data  transfer 
mechanisms  to  suit  application  needs  and  with  future  versions  of  HACP  as  these  are 
defined.  The  LMS  dynamically  determines  which  data  transfer  mechanism  to  use 
when  content  is  launched. 


B.1.3 


Two  Web  Implementations 


5  ECMAScript  is  the  ISO  standard  version  of  JavaScript.  In  this  document  the  use  of  the  term 
“JavaScript”  is  actually  a  reference  to  ECMAScript. 
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The  API  standards  defined  here  may  be  used  to  complement  the  HTTP  standards 
already  defined  in  Appendix  A.  HTTP  may  be  thought  of  as  one  possible 
implementation  for  communication.  In  other  words,  an  LMS  can  support  either  an 
API  or  HTTP  implementation  or  both  implementations  simultaneously. 


B.2 


Two  viewpoints  Conformance  to  this  standard  may  be  looked  at  from  two  viewpoints,  that  of  the 

learning  content  and  that  of  the  LMS. 


B.2.1  Obligation 


Levels  There  are  three  levels  of  obligation  for  the  API's  and  the  data  elements  described  in 

this  standard: 

•  Mandatory 

•  Optional 

•  Extension 

Obligations  for  the  content  and  LMS  are  different. 

For  the  LMS  Mandatory  means  that  the  LMS  shall  perform  the  action  that  the  API  calls  for.  If  the 

action  is  to  return  a  value  to  the  content,  then  the  call  must  succeed  in  returning  a  value 
of  the  proper  format  and  range.  Additionally,  if  the  action  is  for  the  content  to  set  a 
value,  then  that  value  must  assume  the  form  requested  by  the  content,  and  be  returned 
if  requested  in  the  future. 

Optional  means  that  a  conforming  LMS  may  not  respond  at  all  to  the  parameters  in  a 
get  value  or  set  value  call.  A  conforming  LMS  may  support  many  options. 
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For  content 


B.2.2 


An  extension  is  an  API  or  data  element  that  is  not  described  in  this  standard. 
Extensions  may  be  supported  by  an  LMS.  However,  extension  API’s  may  not  perform 
the  same  function  as  a  defined  API;  and  extension  data  elements  may  not  contain  the 
same  semantic  values  as  defined  data  elements.  If  extensions  are  used  to  duplicate 
mandatory  and  optional  features,  the  LMS  is  non-conforming. 

Mandatory  means  that  the  content  shall  execute  the  API.  Only  two  API's  are 
mandatory  for  content:  LMSInitialize  and  LMSFinish. 

Optional  means  that  the  content  may  execute  the  API  with  the  specified  parameter  and 
value  at  least  once.  Furthermore,  the  parameter  and  value  shall  be  in  the  proper  format 
and  range. 

An  extension  is  an  API  or  data  element  that  is  not  described  in  this  standard. 
Extensions  may  be  supported  by  learning  content.  However,  extension  API's  may  not 
perform  the  same  function  as  a  defined  API;  and  extension  data  elements  may  not 
contain  the  same  semantic  values  as  defined  data  elements.  If  extensions  are  used  to 
duplicate  mandatory  and  optional  features,  the  learning  content  is  non-conforming. 


CMI  Responsibilities 


The  mechanism  described  here  assumes  a  clean  separation  between  the  API  function 
calls  used  in  content  and  the  API  implementation.  The  API  function  calls  are 
embedded  in  content.  The  API  implementation  is  provided  by  the  LMS  when  content 
is  launched. 

For  browser  and  Web-based  content,  the  LMS  shall  launch  the  content  from  a  window 
that  contains  the  API  implementation,  or  must  provide  a  parent  frame  that  contains  the 
API  implementation. 

The  API  implementation  provided  by  the  LMS  must  support  all  the  API  function  calls 
described  in  this  document  as  required. 

The  functions  to  “get"  and  “set"  data  element  values  are  generic  in  nature  and  do  not 
specify  particular  data  elements.  Data  elements  can  be  retrieved  from  the  LMS  using 
the  LMSGetValue  function  and  modified  using  a  LMSSetValue  function.  Regardless 
of  implementation  details,  if  a  data  element  is  supported  by  the  LMS,  an  LMSSetValue 
function  call  shall  affect  the  value  returned  by  a  subsequent  LMSGetValue  function 
call  on  that  same  data  element. 

All  return  values  shall  be  strings  which  are  convertible  to  the  designated  data  type. 

The  LMS  shall  support  the  ability  of  the  content  to  “get"  and  “set"  the 
“communication"  data  elements  defined  as  mandatory  in  this  standard.  “Support” 
means  that  when  the  content  executes  an  “  LMSGetValue  “  on  an  element,  a  legal 
value  of  the  proper  format  and  type  and  range  will  be  returned.  When  the  content 
executes  a  legal  “  LMSSetValue  “  on  a  supported  element,  that  value  will  be  taken  and 
the  appropriate  value  returned  when  the  next  “  LMSGetValue  “  on  it  is  executed. 

The  LMS  may  support  the  ability  of  the  content  to  “get”  and  “set”  the  optional  data 
elements. 
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The  LMS  may  also  support  extensions  not  defined  in  this  standard  as  long  as  those 
extensions  do  not  duplicate  any  mandatory  or  optional  features.  Additionally,  the 
support  of  any  extensions  must  not  cause  the  failure  of  any  content  not  using  the 
extensions. 

The  table  below  summarizes  the  requirements  for  a  conforming  LMS. 


LMS  Conformance  Requirements 

-  Supports  the  following  transactions 

•  LMSInitialize 

•  LMSFinish 

•  LMSGetValue 

•  LMSSetValue 

•  LMSCommit 

•  LMSGetLastError 

•  LMSGetErrorString 

•  LMSGetDiagnostic 

-  May  support  security  transactions 

-  Supports  all  mandatory  elements 

•  LMSGetValue  shall  succeed 

•  LMSSetValue  shall  succeed 

-  May  support  any  or  all  optional  elements 

•  LMSGetValue  may  succeed 

•  LMSSetValue  shall  succeed 

-  May  support  extension  elements  if  they  do  not  duplicate 

defined  mandatory  or  optional  elements 

•  LMSGetValue  may  succeed  (or  may  fail) 

•  LMSSetValue  may  succeed  (or  may  be  ignored) 

-  Supported  elements  shall  be  proper  type 

-  Supported  elements  shall  be  in  proper  range 

-  Keywords  are  all  supported _ 
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B.2.3 


Content  Responsibilities 


Content  shall  be  able  to  call  ECMAScript  functions  in  a  “foreign  window”.  The 
content  does  not  have  to  be  developed  in  ECMAScript  but  shall  be  able  to  call  it.  This 
capability  enables  the  clean  separation  between  the  function  calls  used  in  content  and 
the  implementation  of  those  function  calls  provided  by  a  learning  management  system. 

For  conforming  Assignable  Units,  content  shall  call  the  LMSInitialize  function  before 
calling  any  other  API  functions.  If  it  calls  the  Initialize  function  successfully,  it  shall 
also  call  the  LMSFinish  function  before  it  terminates,  even  if  it  does  not  call  any  other 
API  functions. 

Content  may  support  the  required  set  of  “communication”  data  elements  defined  in  the 
AICC/IEEE  Web  CMI  specification. 

The  table  below  summarizes  the  requirements  for  conforming  content. 


Conformance  Requirements  for  Content 

Must  support  the  following  transactions: 

-  Initialize 

-  Zero  or  more  transactions  of: 

-  LMSGetValue(X) 

-  LMSSetValue(X,Y) 

-  Other 

-  Finish 

-  X  is  an  optional  or  extension  data  element 

-  Y  must  be  in  range 

-  Y  must  be  the  right  type _ 


SCORM  (1.0) 


Page  125 


ADL  Sharable  Courseware  Object  Reference  Model 


B.2.3.1 


Binding  Mechanism 


Learning  content  shall  communicate  with  an  LMS  system  through  a  JavaScript  API. 
This  API  will  be  part  of  an  ECMAScript  (JavaScript)  object  attached  to  either  a  parent 
window  or  the  “opener”  window  for  the  HTML  page.  The  content  will  obtain  the  API 
object  by  checking  for  its  existence  on  any  parent  window  or  the  opener  window.  The 
following  JavaScript  example  demonstrates  how  this  might  work: 

//  returns  the  LMS  API  object  (may  be  null  if  not  found) 

FindAPI(win) 

{ 

if  (win.  API  !=  null) 
return  win.API; 
else  if  (win. parent  ==  null) 
return  null; 

else 

return  FindAPI(win. parent); 

} 


//  obtain  the  LMS  API 
API  =  FindAPI(window); 

If  (API  ==  null) 

API  =  FindAPI(window.opener); 


B.2.3.2 


Parameter  Identification 


The  parameters  in  the  API  function  calls  have  two  or  more  parts.  Each  part  is 
separated  by  a  period  (dot).  The  first  part  is  always  the  name  of  the  data  model.  The 
second  part  is  always  the  name  of  an  element  in  the  data  model.  Subsequent  parts  are 
either  the  name  of  an  element  in  the  data  model,  or  a  number,  which  refers  to  a 
location  within  the  preceding  data  element  which,  is  an  array. 

•  datamodel.element 

•  datamodel.element.element 

•  datamodel.element.number.element 

•  datamodel.element.number.element.  number 


Data  model  indicates  which  data  model  the  value  or  return  value  is  based  on.  In  this 
document  the  data  model  is  “CMI”  as  defined  in  the  AICC  and  IEEE  CMI  standards. 

The  highest  level  of  element  is  sometimes  referred  to  as  a  Group  in  the  CMI  data 
model.  In  this  document  the  word  “category”  is  used  interchangeably  with  the  word 
“group.”  Each  group  element  has  a  unique  name  in  the  CMI  data  model. 
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B.3 

The  API’s 


Element  refers  to  a  specific  name  in  the  CMI  data  model.  In  the  AICC  documentation, 
each  element  that  is  a  sub-element  or  member  of  another  element  is  referred  to  as  a 
keyword  or  a  field.  Some  sub-elements  may  have  the  same  name.  To  enable  precise 
identification,  the  element  (sub-element)  name  must  always  be  accompanied  by  the 
name  of  the  group  in  which  it  appears. 

Number  is  a  simple  integer  that  refers  to  the  location  in  an  array,  if  the  named  value  is 
in  an  array.  The  first  element  in  an  array  is  0. 


API  Set 


The  set  of  API  function  calls  consists  of  the  following: 
LMSInitialize() 

LMSFinish() 

LMSGetValue(cmi.group.element) 
LMSSetValue(cmi. group. element,  value) 

LMSCommitO 

LMSGetLastError() 

LM  S  Ge  tErrorS  tring(  erromumber) 
LMSGetDiagnostic(parameter) 

Security  Request/Respond  —  TBD 
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B.3.1 


API  General  Rules 


The  following  list  summarizes  the  usage  rales  for  the  API. 

•  The  function  names  are  all  case  sensitive,  and  must  always  be  expressed 
exactly  as  shown  above. 

•  The  function  parameters  or  arguments  are  case  sensitive.  All  parameters  are 
lower  case. 

•  The  first  symbol  in  the  data  element  name  identifies  the  data  model.  For 
example,  “cmi”  indicates  the  AICC/IEEE  CMI  data  model.  This  expands  the 
functionality  of  these  API’s  by  allowing  the  same  API  to  be  used  with  other 
data  models. 

•  There  are  three  reserved  keywords.  These  are  all  lower  case  and  proceeded 
by  an  underscore. 

■  _version 

■  _children 

■  _count 

•  When  LMSGetValue  is  executed,  it  returns  the  last  set  value  if  there  was  one. 


B.3.2 


Handling  Lists 


There  are  several  data  elements  that  appear  in  a  list  or  an  array.  An  example  of  this 
would  be  objective  status.  There  may  be  more  than  one  objective  covered  in  a  lesson, 
and  a  student  may  be  allowed  to  experience  an  objective  more  than  once. 

To  get  or  set  values  in  a  list,  the  index  number  may  be  used.  The  only  time  an  index 
number  may  be  omitted  is  when  there  is  only  one  member  in  a  potential  list.  Index 
numbering  starts  at  0.  If  a  value  is  to  be  appended  to  the  list,  the  Assignable  Unit  must 
know  the  last  index  number  used. 

If  the  student  is  entering  the  lesson  for  the  second  time,  the  _count  keyword  can  be 
used  to  determine  the  current  number  of  records  in  the  list.  For  instance,  to  determine 
the  number  of  objective  records  currently  recorded,  the  following  API  would  be  used: 
LMSGetValue(“cmi.objective._count”) 

If  the  lesson  does  not  know  the  count  of  the  objective  records,  it  can  begin  the  current 
student  count  with  0.  This  would  overwrite  any  information  about  objectives  currently 
stored  in  the  first  index  position.  Overwriting  or  appending  is  a  decision  that  is  made 
by  the  lesson  author  when  he  creates  the  lesson. 

Elements  in  a  list  are  referred  to  with  a  dot-number  notation  (represented  by  .n).  For 
instance  the  value  of  the  status  element  in  the  first  objective  in  a  lesson  would  be 
referred  to  as  “cmi. objective. 0. status”.  The  status  element  in  the  fourth  objective 
would  be  referred  to  as  “cmi. objective. 3. status”.  If  a  student  experienced  the  first 
objective  twice,  there  could  be  two  status’s  associated  with  the  first  objective.  These 
would  be  identified  as  “cmi. objective.!). status.O”  and  “cmi.objective. 0. status. 1”. 
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B.3.3 

Description 

Syntax 

Parameter 

Return  value 

Examples 

B.3.4 

Description 

Syntax 

Parameter 

Return  value 

B.3.5 

Description 


Initialize 


This  function  indicates  to  the  API  that  the  learning  content  is  going  to  communicate 
with  the  LMS.  It  allows  the  LMS  to  handle  LMS  specific  initialization  issues.  It  is 
called  by  content  before  it  can  call  any  other  API  function. 

LMS  Initialize(parameter) 

Null.  A  null  must  be  passed  for  conformance  to  this  standard.  This  parameter  is 
reserved  for  future  extensions. 

Boolean. 

A  “true”  result  indicates  that  the  initialization  was  successful  and  a  “false”  result 
indicates  that  it  was  not. 

LMSInitializeO 

The  learning  content  tells  the  API  that  the  content  wants  to  establish  communication 
with  the  LMS.  A  typical  return  value  is  “true”. 


Finish 


The  content  must  call  this  function  before  it  terminates,  if  it  successfully  called 
LMSInitialize  at  any  point.  It  signals  to  the  LMS  that  the  content  has  finished 
communicating.  The  content  may  not  call  any  API  function  except  LMSGetLastError 
after  it  calls  LMSFinish.  In  other  words,  all  LMSSetValue  commands  must  be  made 
before  the  LMSFinish  call. 

LMSfinish(parameter) 

Null.  A  null  must  be  passed  for  conformance  to  this  standard.  This  parameter  is 
reserved  for  future  extensions. 

None 


Get  a  Value 


This  function  allows  content  (the  assignable  unit)  to  obtain  information  from  the  LMS. 
It  is  used  to  determine 

•  Values  for  various  categories  (groups)  and  elements  in  the  CMI  data  model. 

•  The  version  of  the  data  model  supported. 

•  Whether  a  specific  category  or  element  is  supported. 

•  The  number  of  items  currently  in  an  array  or  list  of  elements. 
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Syntax 

Parameters 


Return  value 


Examples 
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The  complete  data  element  name  and/or  keywords  are  provided  as  a  parameter.  The 
current  value  of  that  parameter  is  returned.  Only  one  value  —  always  a  string  —  is 
returned  for  each  call. 

LMS  Get  V  alue(parameter) 

cmi. element. element 

Returns  the  value  of  the  named  sub-element 
cmi._version 

The  _version  keyword  is  used  to  determine  the  version  of  the  data  model  supported  by 
the  LMS. 

cmi.element._count 

The  _count  keyword  is  used  to  determine  the  number  of  elements  currently  in  an  array. 
This  number  is  not  changed  by  use  of  the  LMSCommit  call. 

cmi.element._children 

The  _children  keyword  is  used  to  determine  all  of  the  elements  in  a  group  or  category 
that  are  supported  by  the  LMS. 

All  return  values  are  strings  which  can  be  converted  to  the  appropriate  type. 

For  LMSGetValue(cmi. group. element)  the  return  value  is  a  string  representing  the 
current  value  of  the  requested  element  or  group. 

For  LMSGetValue(cmi._version)  the  return  value  is  a  string  representing  the  version 
of  the  data  model  supported  by  the  LMS. 

For  LMSGetValue(cmi.group._children)  the  return  value  is  a  comma  separated  list  of 
all  the  element  names  in  the  specified  group  or  category  that  are  supported  by  the 
LMS.  If  an  element  has  no  children,  but  is  supported,  an  empty  string  is  returned.  If 
an  element  is  not  supported,  there  is  no  return.  A  subsequent  request  for  last  error 
[LMSGetLastErrorQ  ]  can  verify  that  the  element  is  not  supported. 

For  LMSGetValue(cmi.group._count)  the  return  value  is  an  integer  that  indicates  the 
number  of  items  currently  in  an  element  list  or  array. 

LMSGetValue(“cmi.core.student_name'’) 

A  typical  return  value  might  be  “Jackson  Hyde”. 

LMSGetValue(“cmi.core.lesson_status”) 

A  typical  return  value  might  be  “Incomplete”. 

LMSGetV  alue(cmi._version ) 

The  current  draft  standard  for  the  IEEE  document  defining  the  CMI  data  model 
is  entitled  Draft  Standard  for  Computer  Managed  Instruction ,  and  has  an  ID  of 
P  1484.1 1.2  and  a  version  number  of  2.2.  This  call  returns  the  version  number 
of  that  IEEE  document  which  is  2.2. 


131 


CMI001 


AICC 


Appendix  B:  API-based  CMI  Communication 


CMI  Guidelines 


B.3.6 

Description 


Syntax 

Parameter 


Value 

Rev  3.0 
1 -Sep-99 


LMSGetValue(“cmi.student_preferences._children”) 

This  is  a  request  for  category  support.  One  typical  return  value  would  be, 
“audio, speed, text".  If  there  is  no  return,  preferences  are  probably  not 
supported.  An  additional  API  call  to  determine  the  last  error  could  verify  this. 

LMSGetValue(“cmi.comments._children”) 

The  comments  element  has  no  children.  A  zero  length  suing  indicates  that 
comments  are  supported.  No  return  implies  no  support  for  comments. 

LMSGetValue(“cmi. evaluation. comments._children”) 

This  is  a  data  element  request.  The  empty  string  means  that  any  list  of  student¬ 
generated  comments  will  be  forwarded  to  the  LMS.  Further,  this  means  the 
LMS  will,  when  requested,  produce  a  file  matching  the  description  in  the 
“Comments  File”  chapter  of  this  document. 


Set  a  Value 


This  function  allows  the  learning  content  (the  assignable  unit)  to  send  information  to 
the  API.  The  API  may  be  designed  to  immediately  forward  the  information  to  the 
LMS,  or  it  may  be  designed  to  forward  information  based  on  some  other  approach. 
For  instance,  the  API  could  accumulate  the  information  and  forward  everything  to  the 
LMS  when  the  LMSFinish  call  is  executed  by  the  learning  content. 

This  function  is  used  to  set  the  current  values  for  various  categories  (groups )  and 
elements  in  the  CMI  data  model. 

The  data  element  name  and  its  group  are  provided  as  a  parameter.  The  current  value 
of  that  parameter  is  included  in  the  call.  Only  one  value  is  sent  with  each  call. 

LMSSetValue(parameter,  value) 

This  is  the  name  of  a  fully  qualified  atomic  element  defined  in  the  CMI  Data  Model. 
The  argument  is  case  sensitive.  The  argument  is  a  string  surrounded  by  quotes. 

The  following  represents  some  forms  this  parameter  may  take. 

cmi. element 

This  is  the  name  of  a  category  or  group  defined  in  the  CMI  Data  Model.  An  example 
is  “cmi. comments”. 

cmi. element. element 

This  is  the  name  of  an  element  defined  in  the  CMI  Data  Model.  An  example  is 
“cmi. core. student_name”. 

cmi.  element,  n.element 

The  value  of  the  sub-element  in  the  nth-1  member  of  the  element  array  (zero-based 
indexing  is  used). 

This  is  a  string  which  must  be  convertible  to  the  data  type  defined  in  this  standard  for 
the  element  identified  in  the  first  parameter. 
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None 


Send  Cache  to  CMI 


If  the  ECMAScript  is  caching  LMSSetValue  values,  this  call  requires  that  any  values 
not  yet  sent  to  the  LMS  be  sent. 

In  some  implementations,  the  ECMAScript  may  send  the  set  values  to  the  LMS  as 
soon  as  they  are  received,  and  not  cache  them  locally.  In  such  implementations,  this 
API  is  redundant  and  would  result  in  no  additional  action  from  the  ECMAScript. 

LMSCommit(parameter) 

Null.  A  null  must  be  passed  for  conformance  to  this  standard.  This  parameter  is 
reserved  for  future  extensions. 

None 


Determine  Error  Code 


The  learning  content  must  have  a  way  of  assessing  whether  or  not  any  given  API  call 
was  successful,  and  if  it  was  not  successful,  what  went  wrong.  This  routine  returns  an 
error  code  from  the  previous  API  call.  Each  time  an  API  function  is  called  (with  the 
exception  of  this  one,  LMSGetErrorString,  and  LMSGetDiagnostic  —  the  error 
functions),  the  error  code  is  reset  in  the  API.  The  content  may  call  the  error  functions 
any  number  of  times  to  retrieve  the  error  code,  and  the  code  will  not  change  until  the 
next  API  call. 

LMS  GetLastErrorQ 

None. 

The  return  values  are  integer  numbers  that  identify  errors  falling  into  the  following 
categories: 

100  General  errors 

200  Syntax  errors 

300  LMS  errors 

400  Data  model  errors 

The  following  codes  are  available  for  error  messages: 

0.  No  error 

101.  General  exception 

20 1 .  Invalid  argument  error 

202.  Element  cannot  have  children 

203.  Element  not  an  array  -  cannot  have  count 

204.  Element  cannot  have  a  value 
301.  Not  initialized 

401.  Not  implemented  error 
Additional  codes  TBD 


Rev  3.0 
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Obtain  Text  Related  to  Error 


This  function  enables  the  content  to  obtain  a  textual  description  of  the  error 
represented  by  the  error  code  number. 

LMS  GetErrorS  tring  ( errornumber ) 

An  integer  number  representing  an  error  code.. 

A  string  that  represents  the  verbal  description  of  an  error. 


Determine  Vendor-specific  Diagnostics 


This  function  enables  vendor-specific  error  descriptions  to  be  developed  and  accessed 
by  the  content.  These  would  normally  provide  additional  helpful  detail  regarding  the 
error. 

LMSGetDiagnostic(parameter) 

The  parameter  may  take  one  of  two  forms. 

•  An  integer  number  representing  an  error  code.  This  requests  additional 
information  on  the  listed  error  code. 

•  Null  value.  This  requests  additional  information  on  the  last  error  that  occurred. 

The  return  value  is  a  string  that  represents  any  vendor-desired  additional  information 
relating  to  either  the  requested  error  or  the  last  error. 


Security  Request/Respond  -  TBD 
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B.7 

Description 

CMIBlank 

CMIBoolean 

CMIDate 

CMIFeedback 

CMIDecimal 

CMIIdentifier 

CMILocale 

CMIInteger 

CMISIdentifier 

CMISInteger 

CMIString256 

CMIString4096 

CMITime 

CMITimespan 

CMI  Vocabulary 


Rev  3 . 0 
l-Sep-99 


Data  Types 


These  definitions  are  for  the  data  types  used  to  describe  the  format  of  each  data  element.  All  of 
the  data  types  have  the  first  three  characters  of  “CMI"  to  clearly  indicate  they  are  data  types  that 
may  be  unique  to  the  CMI  data  model. 

An  empty  string. 

A  vocabulary  of  two  words,  true  or  false 

A  period  in  time  of  one  day,  defined  by  year,  month,  and  day  in  the  following  numerical  format 
YYYY/MM/DD. 

Structured  description  of  student  response  in  an  interaction. 

Number  which  may  have  a  decimal  point.  If  not  preceded  by  a  minus  sign,  the  number  is 
presumed  to  be  positive.  Examples  are  “2"  and  “2.2”. 

Alphanumeric  group  of  characters  with  no  white  space  or  unprintable  characters  in  it. 

Maximum  of  255  characters. 

A  country  and  a  language. 

An  integer  number  from  0  to  65536. 

CMI  System  Identifier:  Alphanumeric  group  of  characters  that  begins  with  a  single  letter:  A,  B, 
or  J  and  ends  with  an  integer  number.  One  to  five  numerals  may  follow  the  letter.  See  System 
Identifier. 

A  signed  integer  number  from  -32768  to  +32768. 

A  set  of  ASCII  characters  with  a  maximum  length  of  255  characters. 

A  set  of  ASCII  characters  with  a  maximum  length  of  4096  characters. 

A  chronological  point  in  a  24  hour  clock.  Identified  in  hours,  minutes  and  seconds  in  the 
format:  HH:MM:SS.S  Hours  and  seconds  shall  contain  two  digits.  Seconds  shall  contain  2 
digits  with  an  optional  decimal  point  and  additional  digits. 

A  length  of  time  in  hours,  minutes,  and  seconds  shown  in  the  following  numerical  format: 
HHHH:MM:SS.S  Hours  and  seconds  shall  contain  two  or  more  digits.  Hours  has  a  maximum 
of  4  digits.  Minutes  shall  consist  of  2  digits.  Seconds  shall  contain  2  digits  with  an  optional 
decimal  point  and  additional  digits. 

Used  to  attach  specific  vocabularies  within  contexts  in  a  schema.  Vocabulary  words  must  be 
complete  and  exact  matches  to  those  below.  Single  letters  and  abbreviations  may  not  be  used  in 
API  communication.  The  following  are  vocabularies  included  in  the  CMI  Data  Model: 
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Vocabulary  Type 

Members  of  Vocabulary 

Mode 

normal 

review 

browse 

Status 

passed 

completed 

failed 

incomplete 

browsed 

not  attempted 

Exit 

time-out 

suspend 

logout 

Why-left 

student  selected 

lesson  directed 

exit 

directed  departure 

Credit 

credit 

no  credit 

Entry 

ab-initio 

resume 

Time  Limit  Action 

exit 

continue 

message 

no  message 

Interaction 

true-false 

multiple  choice 

fill  in  the  blank 

matching 

simple  performance 

likert 

sequencing 

unique 

numeric 

Result 

correct 

wrong 

unanticipated 

neutral 

x.x  (CMIDecimal) 

Rev  3.0.1 
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B.8 


Data  Comparison 


Description  The  following  tables  compare  the  Group  and  Keyword  names  used  in  file-based 

communication,  with  the  data  element  names  used  in  API  communications.  The  tables 
indicate  where  there  are  differences  and 

•  Why  a  new  element  was  created 

•  Why  a  keyword  was  deleted 

•  Why  a  group  or  keyword  name  was  changed. 


Table  of  CMI  to  Lesson  Communication 


Data  Model  Name 

Group/Keyword 

Title 

Why  Different 

core 

[Corel 

|-student  id 

StudentJD 

|-student  name 

Student_Name 

Output_File 

Only  needed  for  file-based 
communication. 

|-lesson  location 

Lesson_Location 

| -credit 

Credit 

|-lesson  status 

Lesson_Status 

l-entry 

status  flap 

Need  separate  variable  for  every  value 

l-score 

Score 

|-|-raw 

Need  separate  variable  for  every  value 

|~|-max 

Need  separate  variable  for  every  value 

| — |— min 

Need  separate  variable  for  every  value 

l-total  time 

Time 

Avoid  get  and  set  time  ambiguity. 

l-lesson  mode 

Lesson_Mode 

suspend  data 

[Core  Lessonl 

Name  better  describes  the  data. 

launch_data 

[Core  Vendorl 

Name  better  describes  the  data. 

comments 

[Commentsl 

evaluation 

[Evaluation! 

|--course  id 

CourseJD 

|-comments 

Comments  File 

API  communication  does  not  use  files. 

|-interactions 

lnteractions_File 

API  communication  does  not  use  files. 

— objectives_status 

Objectives  Status 
File 

API  communication  does  not  use  files. 

l-path 

PathFile 

API  communication  does  not  use  files. 

|-performance 

Performance_File 

API  communication  does  not  use  files. 

Rev  3.0.1 
24-Nov-99 
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Table  of  CMI  to  Lesson  Communication  (cont.) 


Data  Model  Name 

Group/Keyword 

Title 

Why  Different 

objectives 

[Objectives  Statusl 

Status  is  only  one  element  in  this  group. 

1— id 

JID.1 

Objectives  relationship  established  by 
parent  name  (i.e. ,  objectives. n. id) 

|-scores 

J_Score.1 

Plural  convention  for  possible  array. 

|-|-raw 

Need  separate  variable  for  every  value 

|-|-max 

Need  separate  variable  for  every  value 

| — |— min 

Need  separate  variable  for  every  value 

—statuses 

J_Status.1 

Objectives  relationship  established  by 
parent  name  (i.e.,  objectives. n. status) 

student_data 

[Student  Datal 

|-attempt  number 

Attempt  Number 

|-mastery  score 

Mastery  Score 

— max_time_ 
allowed 

Max_Time_ 

Allowed 

—-time  limit  action 

Time_Limit_Action 

— attemp—records 

Must  have  a  name  with  no  value  to 
enable  children. 

— |-lesson_scores 

Score.  1 

Plural  for  array  convention.  Added  lesson 
for  consistency  with  status. 

lessonstatuses 

Lesson_Status.1 

Plural  convention  for  possible  array. 

studen— 

demographics 

[Studen— 

Demographicsl 

l-city 

City 

| -class 

Class 

| -company 

Company 

| -country 

Country 

—experience 

Experience 

—-familiar  name 

Familia—Name 

—-instructor  name 

Instructo—Name 

—-title 

Job_Title 

Generalize  person’s  title. 

—native  language 

Native  Language 

| -state 

State 

—-street  address 

Street  Address 

—telephone 

Telephone 

— years_ 
experience 

Years_Experience 

Rev  3.0.1 
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Table  of  CMI  to  Lesson  Communication  (cont.) 


Data  Model  Name 

Group/Keyword 

Title 

Why  Different 

student_ 

preference 

[Student_ 

Preferences! 

Singular  because  not  an  array. 

-audio 

Audio 

-language 

Language 

-lesson  type 

Lesson  Type 

-speed 

Speed 

-text 

Text 

-text  color 

Text  Color 

_ 

-textjocation 

Text_Location 

-text_size 

Text_Size 

-video 

Video 

-windows 

Window. 1 

Plural  convention  for  arrays. 

Table  of  Lesson  to  CMI  Communication 


Data  Model  Name 

Group/Keyword 

Title 

Why  Different 

core 

[Corel 

|-lesson  location 

Lesson_Location 

|-lesson  status 

Lesson  Status 

1;— exit 

status  flag 

Need  separate  variable  for  every  value 

l-score 

Score 

|--|~raw 

Need  separate  variable  for  every  value 

|-|-max 

Need  separate  variable  for  every  value 

| — |— min 

Need  separate  variable  for  every  value 

|-session  time 

Time 

Avoid  get  and  set  time  ambiguity. 

suspend  data 

[Core  Lesson! 

Name  better  describes  the  data. 

comments 

[Commentsl 

objectives 

[Objectives  Statusl 

Status  is  only  one  element  in  this  group. 

|— id 

JID.1 

Objectives  relationship  established  by 
parent  name  (i.e. ,  objectives. n. id) 

| -scores 

J_Score.1 

Plural  convention  for  possible  array. 

|-|-raw 

Need  separate  variable  for  every  value 

j-j-max 

Need  separate  variable  for  every  value 

| — |— min 

Need  separate  variable  for  every  value 

—statuses 

J_Status.1 

Objectives  relationship  established  by 
parent  name  (i.e.,  objectives. n. status) 

Rev  3.0.1 
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Table  of  Lesson  to  CMI  Communication  (cont.) 


Data  Model  Name 

Group/Keyword 

Title 

Why  Different 

student  data 

[Student  Datal 

— tries_during_ 
lesson 

Tries_During_ 

Lesson 

l-tries 

Need  name  for  parent. 

— |-score 

TryScore.l 

Relationship  to  tries  established  by  parent 
name. 

raw 

Need  separate  variable  for  every  value 

|-|-|-max 

Need  separate  variable  for  every  value 

1 — |— |— min 

Need  separate  variable  for  every  value 

— |-status 

Try_Status.1 

Relationship  to  tries  established  by  parent 
name. 

|— |— time 

Try_Time.1 

Relationship  to  tries  established  by  parent 
name. 

student_ 

preference 

[Student_ 

Preferences! 

Singular  for  non-array. 

-audio 

Audio 

-language 

Language 

-lesson  type 

Lesson  Type 

-speed 

Speed 

-text 

Text 

-text  color 

Text  Color 

-text  location 

Text  Location 

-text  size 

Text  Size 

-video 

Video 

-windows 

Window.  1 

Rev  3.0.1 
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CM I  Guidelines 


Table  of  Lesson  Evaluation  Data 

In  a  web  environment  all  Lesson  Evaluation  information  must  pass  through  the  CMI  system  before  it  can  be  stored 
in  standard  files.  Each  of  the  fields  in  the  set  of  Lesson  Evaluation  files  becomes  just  another  data  element  that  is 
being  passed  to  the  CMI.  The  CMI  is  responsible  for  assembling  this  information  plus  any  additional  information 
that  is  required  from  the  Lesson  to  LMS  table  to  create  the  files  specified  in  this  standard. 


Data  Model  Name 

Field  Title 

Why  Different 

CourseJD 

CMI  already  has  this  information.  Do  not 
need  to  return  it  to  the  CMI. 

StudentJD 

CMI  already  has  this  information.  Do  not 
need  to  return  it  to  the  CMI. 

lessonjd 

Lesson  ID 

date 

Date 

comments 

Comments  File 

|--time 

Time 

|--location 

Location 

--content 

Comment 

Content  of  comment.  Keeping  comment 
would  be  redundant. 

interactions 

Interactions  File 

CourseJD 

Superflous  (see  above). 

StudentJD 

Superflous  (see  above). 

Lesson  ID 

Already  in  data  model.  (See  above) 

|— id 

InteractionJD 

Full  name  superflous  in  data  model. 
(Appears  as  interactions. id) 

l-objective  ids 

Objective  ID 

Plural  for  array  names. 

Date 

Already  in  data  model.  (See  above) 

l-time 

Time 

|— type 

Type  Interaction 

|-responses 

Need  name  for  parent. 

|--|— description 

Correct_Response 

More  accurate  term.  Element  can 
represent  incorrect  answers  as  well  as 
correct. 

|— |— value 

Response  Value 

|~weighting 

Weighting 

— student_ 
response 

Student_Response 

|-result 

Result 

|-latency 

Latency 

Rev  3 . 0 
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Table  of  Lesson  Evaluation  Data  (cont.) 


Data  Model  Name 

Field  Title 

Why  Different 

objectives 

Objectives  Status 

File 

Same  as  objectives  in  lesson  to  LMS 
data. 

CourseJD 

Superflous  (see  above). 

StudentJD 

Superflous  (see  above). 

Lesson_ID 

Already  in  data  model.  (See  above) 

Date 

Already  in  data  model.  (See  above) 

Time 

Passed  with  objectives  information  in 
Lesson  to  LMS  data. 

Objective  ID 

In  lesson  to  LMS  data  under  objectives. 

Score 

In  lesson  to  LMS  data  under  objectives. 

Status 

In  lesson  to  LMS  data  under  objectives. 

— -masteryjime 

Mastery_Time 

Must  added  to  objectives  in  lesson  to 

LMS  data. 

paths 

Path  File 

CourseJD 

Superflous  (see  above). 

Student  ID 

Superflous  (see  above). 

LessonJD 

Already  in  data  model.  (See  above) 

Date 

Already  in  data  model.  (See  above) 

|-location  id 

Element_Location 

Element  location  is  an  ID. 

l-time 

Time 

|--status 

Status 

|--why  left 

Why  Left 

|-time  in  element 

TimeJn_Element 

Rev  3 . 0 
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1  Background  Information 


1.1  Creation  of  this  document 

This  document  has  been  created  at  the  request  of  the  IEEE  LTSC  P1484.12  Learning  Object  Metadata  (LOM) 
Working  Group.  This  draft  document  is  to  represent  the  best  possible  convergence  of  all  the  information  collected 
to  date,  input  from  the  working  group  and  existing  work  in  this  area. 

This  version  3.8  incorporates  further  work  on  version  3.7,  posted  on  October,  24,  1999  to  the  LOM  mailing  list,  as 
documented  in  section  1.4  Revisions. 

1.2  Disclaimers 

This  document  is  a  proposal  for  the  next  Working  Draft  of  the  IEEE  1484.12  Working  Group.  It  is  the  latest  in  a 
series  of  versions  that  have  been  discussed  at  the  meetings  of  the  working  group  and  on  the  mailing  list,  as 
documented  in  section  1.4. 

Copyright  (C)  1999  IEEE.  Do  not  use  or  claim  conformance  to  this  document. 


1.3  Submitting  comments  and  corrections 

Please  send  all  comments  and  corrections  via  Email  to  <wayne.hodgins@autodesk.com>. 

1.4  Revisions 

The  previous  release  of  the  LOM  specification  was  version  3.7,  distributed  through  the  LEARNING-OBJECTS 
mailing  list  on  October,  24  1999. 

Based  on  discussions  after  the  release  of  version  3.7,  a  number  of  further  modifications  have  been  made  to  the 
specification.  These  are  listed  below: 

•  section  3.2: 

o  added  note  “these  typically  refer  to  other  standards  (section  9)  or  vocabularies  (section  3.4)“  to 
explanation  of  domain  (based  on  comment  from  Dan  Rehak); 

o  replaced  “In  that  case,  only  the  lowest  level  subelement  shall  have  a  value.”  by  “Elements  with 
subelements  shall  not  have  values  directly;  only  elements  with  no  subelements  shall  have  values 
directly.  Elements  with  subelements  shall  have  values  indirectly  only,  through  their  subelements.” 
(based  on  comment  from  Dan  Rehak); 

•  section  3.4: 

o  repeated  example  with  index  value  as  representation  for  entry  (based  on  comment  from  Dan 
Rehak); 

o  replaced  “If  the  entry  is  an  item  from  the  vocabulary,  then  the  detail  is  optional.  If  present,  the 
detail  provides  additional  specialization  of  the  entry.”  by  “If  the  entry  is  an  item  from  the 
vocabulary,  then  the  detail  can  be  null.  If  not  null,  then  the  detail  provides  additional 
specialization  of  the  entry.”  (based  on  comment  from  Dan  Rehak); 

•  section  3.7: 

o  replaced  “For  instance,  a  derived  scheme  can  define  some  elements  as  mandatory  that  are  optional 
or  conditional  in  the  Base  Scheme.”  by  “For  instance,  a  derived  scheme  can  restrict  a  vocabulary 
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for  an  element  to  a  subset  of  the  vocabulary  defined  herein.”  (based  on  comment  from  Dan 
Rehak); 

•  section  5  and  section  6: 

o  replaced  “unordered  list”  by  “multiple  unordered  instance”  for  elements  with  subelements 
(suggestion  from  Dan  Rehak); 

o  replaced  “ordered  list”  by  “multiple  ordered  instance”  for  elements  with  subelements  (suggestion 
from  Dan  Rehak); 

o  for  elements  with  subelements,  the  terminology  “single  instance”  was  already  in  use; 

o  changed  minmax  value  4,  8,  16  or  32  for  list  items  to  5,  10,  15  or  30  (suggestion  from  Dan 
Rehak); 

•  section  5: 

o  changed  wording  (but  not  intended  meaning!)  of  explanation  throughout  (suggestions  from  Phill 
Dodds,  Frank  Farance,  Wayne  Hodgins,  Dan  Rehak  and  Tom  Wason); 

•  section  6: 

o  1 . 1  :LangString. Language:  changed  minmax  from  120  to  100  (suggestion  from  Dan  Rehak); 

•  section  5,  6  and  7: 

o  Removed  notes  column:  absorbed  it  into  explanation  and  domain,  as  appropriate  (based  on 
suggestion  from  Scott  Lewis). 

•  section  8: 

o  2:Detail:  changed  explanation  to  “Additional  detail  on  the  vocabulary  entry.”  (based  on  comment 
from  Dan  Rehak); 

•  throughout: 

o  many  editorial  changes,  including  appropriate  use  of  ‘shall’  and  ‘may’  (based  on  comments  from 
Scott  Lewis); 

The  LOM  standard  is  being  developed  in  IEEE  1484.12.  Further  information  on  past  and  current  revisions  may  be 
found  at  <http://ltsc  .ieee.org/wgl  2>. 

1.5  Acknowledgements 

The  IEEE  LTSC  P1484.12  LOM  working  group  wishes  to  thank  Erik  Duval,  Tom  Wason  and  Wayne  Hodgins  for 
their  tireless  efforts  and  commitment  to  developing  a  high  quality  solution  and  document. 

This  document  has  its  origins  in  both  the  ARIADNE  <http://ariadne.unil.ch>  and  IMS  <http://ww w. imsproj ec  t.  org> 
Projects,  without  which  this  document  could  not  have  been  created. 

This  document  also  builds  on  metadata  work  done  by  the  Dublin  Core  group  <http://purl.org/do. 


2  Introduction 

Metadata  is  information  about  an  object,  be  it  physical  or  digital.  As  the  number  of  objects  continues  to  grow 
exponentially  and  especially  as  our  needs  for  learning  expand  equally  dramatically,  the  lack  of  information  or 
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metadata  about  objects  has  produced  a  critical  and  fundamental  constraint  on  our  ability  to  discover,  manage  and  use 
objects.  To  address  this  problem,  the  IEEE  LTSC  LOM  working  group  has  created  a  standard  for  “Learning  Object 
Metadata”.  This  is  the  first  documentation  of  this  work  and  describes  the  structured  metadata  model,  which  has 
been  developed  by  the  working  group. 

2.1  Scope 

This  standard  specifies  the  syntax  and  semantics  of  1  earning  objectmetadata ,  defined  as  the  attributes  required  to 
fully  and  adequately  describe  a  learning  object.  A  learning  object  is  defined  here  as  any  entity,  digital  or  non¬ 
digital,  that  can  be  used,  re-used  or  referenced  during  technology-supported  learning.  Examples  of  technology- 
supported  learning  applications  include  computer-based  training  systems,  interactive  learning  environments, 
intelligent  computer-aided  instruction  systems,  distance  learning  systems,  web-based  learning  systems  and 
collaborative  learning  environments. 

Examples  of  learning  objects  include  multimedia  content,  instructional  content,  instructional  software  and  software 
tools  that  are  referenced  during  technology  supported  learning.  In  a  wider  sense,  learning  objects  could  include 
learning  objectives,  persons,  organizations,  or  events. 

The  LOM  standards  focuses  on  the  minimal  set  of  properties  needed  to  allow  learning  objects  to  be  managed, 
located,  and  evaluated.  The  standard  accommodates  the  ability  for  locally  extending  the  minimal  set  of  properties. 

Relevant  properties  of  learning  objects  include  type  of  object,  author,  owner,  terms  of  distribution,  and  format. 
Where  applicable,  learning  object  metadata  may  include  pedagogical  properties,  such  as  teaching  or  interaction 
style,  grade  level,  mastery  level  and  prerequisites.  Any  given  learning  object  can  have  more  than  one  description 
(i.e.,  LOM  set  or  instance  of  the  metadata  scheme  defined  below). 

The  standard  supports  security,  privacy,  commerce,  and  evaluation,  but  only  to  the  extent  that  metadata  fields  are 
provided  for  specifying  descriptive  tokens  related  to  these  areas;  the  standard  does  not  concern  itself  with  how  these 
features  are  implemented.  The  LOM  standard  references  existing  open  standards  and  existing  work  in  related  areas. 
For  example,  the  data  scheme  below  takes  into  account  the  efforts  to  standardize  the  description  of  content  objects  in 
general,  as  developed  in  the  Dublin  Core  Metadata  Initiative. 

2.2  Purpose 

1.  To  enable  learners  or  instructors  to  search,  evaluate,  acquire,  and  use  learning  objects. 

2.  To  enable  sharing  and  exchanging  of  learning  objects  across  any  technology-supported  learning  system. 

3.  To  enable  developing  learning  objects  in  units  that  can  be  combined  and  decomposed  in  meaningful  ways. 

4.  To  enable  computer  agents  to  automatically  and  dynamically  compose  personalized  lessons  for  an 
individual  learner. 

5.  To  complement  the  direct  work  on  standards  that  are  focused  on  enabling  multiple  Learning  Objects  to 
work  together  within  an  open,  distributed,  learning  environment. 

6.  To  enable  documenting  and  recognizing  the  completion  of  existing  or  new  learning  and  performance 
objectives  associated  with  Learning  Objects. 

7.  To  enable  a  strong  and  growing  economy  for  Learning  Objects  that  supports  and  sustains  all  forms  of 
distribution;  non  profit,  not-for-profit  and  for  profit. 

8.  To  enable  education,  training  and  learning  organizations,  including  government,  public  and  private,  to 
express  educational  content  and  performance  standards  in  a  standardized  format  that  is  independent  of  the 
content  itself. 
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9.  To  provide  researchers  with  standards  that  support  collecting  and  sharing  comparable  data  concerning  the 
applicability  and  effectiveness  of  Learning  Objects. 

10.  To  define  a  standard  that  is  simple  yet  extensible  to  multiple  domains  and  jurisdictions  so  as  to  be  most 
easily  and  broadly  adopted  and  applied. 

11.  To  support  necessary  security  and  authentication  for  the  distribution  and  use  of  Learning  Objects. 

3  Overview  of  the  Metadata  Structure 


3.1  Basic  metadata  structure 

The  structured  approach  to  metadata  definition  implies  that  the  actual  descriptors  (that  together  form  a  conventional, 
standardized  description)  of  a  learning  resource  -  the  learning  object  -  are  grouped  into  meaningful  categories.  The 
Base  Scheme  shall  consist  of  nine  such  categories: 

1 .  General  shall  group  all  context-independent  features  plus  the  semantic  descriptors  for  the  resource. 

2.  Lifecycle  shall  group  the  features  linked  to  the  lifecycle  of  the  resource. 

3.  Meta-metadata  shall  group  the  features  of  the  description  itself  (rather  than  those  of  the  resource  being 
described). 

4.  Technical  shall  group  the  technical  features  of  the  resource. 

5.  Educational  shall  group  the  educational  and  pedagogic  features  of  the  resource. 

6.  Rights  shall  group  the  features  that  deal  with  the  conditions  of  use  for  the  resource. 

7.  Relation  shall  group  features  of  the  resource  that  link  it  to  other  resources. 

8.  Annotation  shall  allow  for  comments  on  the  educational  use  of  the  resource. 

9.  Classification  shall  group  characteristics  of  the  resource  described  by  entries  in  classifications. 

Taken  all  together,  these  categories  form  what  is  called  here  the  Base  Scheme. 

3.2  Data  elements 

Categories  shall  contain  data  elements.  For  each  element,  the  base  scheme  shall  define: 

•  name:  shall  describe  how  the  meta-data  element  is  called; 

•  explanation:  shall  define  the  definition  of  the  element; 

•  multiplicity:  shall  define  how  many  elements  are  allowed  and  whether  their  order  is  significant  (see  also 
section  3.5); 

•  domain:  shall  define  constraints  on  appropriate  values  for  the  data  element  -  these  typically  refer  to  other 
standards  (section  9)  or  vocabularies  (section  3.4); 

•  type:  shall  define  whether  the  element’s  value  is  textual,  a  date  or  a  reserved  element; 

•  note:  shall  define  additional  explanations,  guidelines  for  using  the  element,  etc.; 

•  example 
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Both  the  multiplicity  and  type  information  can  include  minmax  values  (see  section  3.6). 

Some  data  elements  contain  subelements.  Elements  with  subelements  shall  not  have  values  directly;  only  elements 
with  no  subelements  shall  have  values  directly.  Elements  with  subelements  shall  have  values  indirectly  only, 
through  their  subelements.  As  an  example,  1 .3:General.CatalogEntrv  has  a  value  indirectly  only,  through 
1.3.1  :General.CatalogEntry.Catalogue  and  1 . 3 . 2 : General . C at alo gEnt r y . Entr y . 


3.3  List  values 

In  some  instances,  a  data  element  contains  a  list  of  values,  rather  than  a  single  value.  This  list  shall  be  one  of: 

•  ordered:  shall  specify  that  the  order  of  the  values  in  the  list  is  important.  For  example,  in  a  list  of  authors 
of  a  publication,  the  first  author  is  often  considered  the  more  important  one. 

•  unordered:  shall  specify  that  the  order  of  the  values  bears  no  meaning.  For  example,  if  the  description  of  a 
simulation  includes  three  short  texts  that  describe  the  intended  educational  use  in  three  different  languages 
(for  instance  French,  German  and  Italian),  then  the  order  of  these  texts  not  significant  and  they  may  appear 
in  any  order  without  loss  of  information. 

A  list  of  values  shall  contain  at  least  one  element.  Implementations  may  use  a  list  of  zero  length  for  internal 
operations,  but  an  element  with  a  zero  length  list  shall  not  be  distinguishable  from  an  element  with  no  value.  Where 
a  value  is  required,  a  zero-length  list  shall  not  be  valid  as  a  final  value. 

If  an  element  with  subelements  contains  a  list  of  values,  then  each  of  these  values  shall  be  a  tuple  of  subelements. 
For  example,  the  base  scheme  defines  that  the  element  1 .3  :General.CatalogEntry  contains  an  unordered  list  of  values 
for  the  subelements  1.3.1  :General.CatalogEntry.Catalogue  and  1.3.2:General.CatalogEntry.Entrv.  In  other  words, 
the  Base  Scheme  defines  that  the  value  of  the  element  1 .3:General.CatalogEntry  is  an  unordered  list  of 
(1.3.1  :General.CatalogEntrv.Catalogue.  1 ,3.2:General.CatalogEntrv.Entrv)  elements. 


3.4  Vocabularies 

For  some  data  elements,  vocabularies  are  defined.  A  vocabulary  shall  be  a  list  of  appropriate  values.  Vocabularies 
shall  be  one  of: 

•  restricted:  shall  specify  that  only  the  values  from  the  list  specified  in  this  document  are  acceptable. 

•  best  practice :  A  list  of  suggested  best -practice  values  is  provided  that  should  be  used,  but  other  values  may 
be  used. 

For  data  elements  with  associated  vocabularies,  the  value  shall  be  represented  as  a  two  element  tuple  (entry,  detail). 
The  entry  shall  be  an  item  from  the  vocabulary.  For  data  elements  with  an  associated  best-practice  vocabulary,  the 
entry  may  also  be  “User_defined”,  or  “See_classification”. 

•  If  the  entry  is  an  item  from  the  vocabulary,  then  the  detail  may  be  null.  If  not  null,  then  the  detail  shall 
provide  additional  specialization  of  the  entry.  In  this  way,  the  detail  shall  further  refine  the  vocabulary 
term  with  an  additional  term  provided  by  the  user. 

•  If  the  entry  equals  “User  dcfined”,  then  the  detail  element  shall  belong  to  a  vocabulary  not  defined  herein. 

•  If  the  entry  equals  “See_classification",  then  the  detail  element  shall  belong  to  a  vocabulary  identified  by 
an  instance  of  the  9 Classification  category,  whose  value  for  9. 1  :Classification.Purpose  shall  equal  the 
name  of  the  element  with  the  best  practice  vocabulary. 

As  an  illustration,  we  give  examples  of  the  different  cases  for  the  element  5.2:Educational.LearningResourceType: 

•  The  simplest  case  is  just  an  item  from  the  vocabulary,  for  instance  “Questionnaire”.  This  would  be 
represented  as  (“Questionnaire”, null) 

•  A  somewhat  more  complex  case  is  an  item  from  the  vocabulary,  with  an  additional  detail  element,  as  in 
(“Questionnaire’V’Multiple  Choice  Questionnaire”). 
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•  If  the  user  wants  to  include  a  value  that  is  not  part  of  the  list  of  5.2:Educational.LearningResourceType, 
then  the  most  simple  case  relies  on  the  “User_defined”  value  for  the  entry,  as  in  (“User_defined”, 
“MotivatingExample”) . 

•  If  the  user  wants  to  include  a  value  from  an  existing  classification,  then  he  or  she  can  do  so  through  the 
“See_classsification”  value  for  the  entry,  as  in  (“See_classification'’,”xxx'’).  In  this  case,  there  must  be  a 
value  for  9:Classification,  whose  9. 1  :Classification. Purpose  equals  “LearningResourceType”.  The  value  of 
9.2.  l:Classification.TaxonPath. Source  will  then  define  the  classification  that  “xxx”  comes  from. 

A  vocabulary  provided  by  this  specification  is  a  list  of  “enumerated  values”.  The  (entry)  value  shall  be  represented 
as  an  index  value,  as  listed  in  the  appropriate  vocabulary.  The  (entry)  value  “User_defined”  shall  be  represented  as 
1  and  “See_classification”  shall  be  represented  as  2.  Numbers  of  3  and  higher  refer  to  specific  vocabulary  items  as 
defined  in  the  Base  Scheme  (Section  5).  See  also  section  8.  The  (detail)  value  of  the  tuple  shall  be  represented  as  a 
LangString. 

So,  the  example  above  would  be  represented  as: 

•  (“Questionnaire”,null):  (5, null) 

•  (“Questionnaire’Y’Multiple  Choice  Questionnaire”):  (5,”Multiple  Choice  Questionnaire”) 

•  (“User_defined”,  “MotivatingExample”):  ( 1 /’MotivatingExample”) 

•  (“See_classification”,”xxx”):  (2,”xxx”) 

3.5  Minmax  values 

In  the  base  scheme,  minmax  values  are  defined  for: 

•  elements  with  a  list  value:  All  applications  shall  support  at  least  that  number  of  entries  for  the  list.  In  other 
words:  an  application  may  impose  a  maximum  on  the  number  of  entries  it  supports  for  the  list  value  of  that 
element,  but  that  maximum  shall  not  be  lower  than  the  minmax  value. 

•  elements  with  type  String  or  LangStringType:  All  applications  shall  support  at  least  that  length  for  the 
String  value  (either  directly  or  contained  in  the  LangS trin gT ype)  of  that  element.  In  other  words:  an 
application  may  impose  a  maximum  on  the  number  of  characters  it  supports  for  the  string  value  of  that 
element,  but  that  maximum  shall  not  be  lower  than  the  minmax  value  for  the  type  of  the  element. 


3.6  Character  sets 

This  standard  defines  a  conceptual  structure  for  learning  object  metadata.  It  does  not  deal  with  representation  issues, 
which  will  be  dealt  with  in  separate  documents.  Whatever  decisions  are  made  in  documents  that  deal  with 
representation,  it  is  a  firm  expectation  by  the  contributors  of  the  LOM  document  that  such  decisions  will  be  taken 
with  a  view  to  support  multiple  languages.  This  will  have  important  repercussions  with  respect  to  the  character  sets 
to  be  supported. 

3.7  Derived  schemes 

The  metadata  structure  defined  in  this  document  is  called  the  Base  Scheme.  From  the  Base  Scheme,  other  schemes 
may  be  derived.  Derived  schemes  shall  inherit  the  structure  from  which  they  are  derived.  A  derived  scheme  may 
add  additional  categories  and  data  elements,  but  only  to  describe  characteristics  not  taken  into  account  in  the  Base 
Scheme.  A  common  Base  Scheme  provides  a  high  degree  of  interoperability  and  similarity  among  different  derived 
schemes. 

It  is  important  to  note  that  the  properties  described  by  optional  data  elements  shall  be  described  through  these 
optional  elements  only  and  no  overlapping  data  elements  shall  be  introduced. 
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A  particular  derived  scheme  may  be  more  restrictive.  For  instance,  a  derived  scheme  can  restrict  a  vocabulary  for  an 
element  to  a  subset  of  the  vocabulary  defined  herein.  But  a  derived  scheme  shall  not  be  less  restrictive. 


3.8  Indexation 

One  should  be  aware  of  the  fact  that  not  all  values  for  data  elements  need  to  be  specified  manually  by  each 
individual  indexer  or  searcher.  In  many  cases,  the  values  could  come  from  automated  processes  or  templates  that 
specify  what  is  common  for  a  number  of  objects.  This  implies  that  a  user  describing  objects,  or  someone  searching 
for  appropriate  material,  would  only  be  confronted  with  a  subset  of  the  elements  in  the  Base  Scheme. 

3.9  Representation 

For  each  of  the  data  elements,  the  specification  includes  the  data  type  from  which  it  derives  its  values,  such  as 
LangS trin gT ype  or  DateType.  and  so  forth.  These  will  be  defined  separately,  and  will  be  implemented  in  a 
particular  way  in  a  particular  system.  To  maximize  interoperability,  future  work  may  define  a  common 
representation  for  these  data  types.  In  the  absence  of  such  a  common  representation,  an  exchange  format,  such  as 
XML,  would  allow  systems  with  different  representations  to  achieve  interoperability  through  a  conversion  process. 

4  Conformance 

A  metadata  instance  shall  conform  to  this  standard  if  it  satisfies  the  following  four  requirements: 

1.  The  metadata  instance  shall  contain  one  or  more  LOM  element(s). 

2.  All  LOM  elements  in  the  metadata  instance  shall  describe  characteristics  as  defined  by  the  LOM 
specification. 

(For  example,  the  user  shall  not  abuse  the  title  element  to  describe  the  fonts  used  in  the  document.) 

3.  Values  for  LOM  elements  in  the  metadata  instance  shall  be  structured  as  defined  by  the  LOM  specification 
and  this  structural  information  shall  be  carried  within  the  instance. 

(This  means  that  the  grouping  in  categories  and  subelements  must  be  maintained.  But  it  does  not  mean  that 
representations  cannot  define  mappings  of  this  structure  as  they  see  fit.  More  specifically,  an  XML 
representation  can  use  the  lang  attribute  to  represent  the  Language  element  of  a  LangS  trin  gT ype  value.) 
or 

Bindings  must  carry  equivalent  information  about  the  metadata  so  that  conversions  between  bindings  do 
not  induce  loss  of  information  as  defined  within  this  standard. 

4.  If  the  instance  contains  extensions  to  the  LOM  structure,  then  extension  elements  shall  not  replace  elements 
in  the  LOM  structure. 
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9.2  Miscellaneous 


•  Dublin  Core:  The  Dublin  Core  is  a  metadata  element  set  intended  to  facilitate  discovery  of 
electronic  resources,  <http://purl.org/dc/> 

•  ISO  639:  This  is  an  international  standard  for  the  representation  of  languages.  Version  1  uses  two- 
letter  language  codes,  e.g.  ‘en’  for  English,  ‘fr’  for  French,  ‘nl’  for  Dutch,  and  so  forth.  These 
language  codes  are  a  basis  for  the  IETF  registry  of  language  tags,  as  specified  in  RFC  1766:  Tags 
for  the  identification  of  languages. 

•  ISO  646:  This  is  an  international  standard  that  defines  the  ASCII  character  set. 

•  ISO  3166:  This  is  an  international  standard  for  the  representation  of  country  names,  e.g.  ‘BE’  for 
Belgium,  ‘CA’  for  Canada,  ‘FR’  for  France,  ‘GB’  for  United  Kingdom,  ‘US’  for  United  States, 
etc.  <http://www.din.de/gremien/nas/nabd/iso3166ma/codlstpl.html> 

•  ISO  8601:  This  is  an  international  Standard  that  specifies  numeric  representations  of  date  and 
time.  The  basic  notation  is  YYYY-MM-DD  where  YYYY  is  the  year  in  the  usual  Gregorian 
calendar,  MM  is  the  month  of  the  year  between  01  (  January)  and  12  (December),  and  DD  is  the 
day  of  the  month  between  01  and  31.  <http://www.cl.cam.ac.uk/~mgk25/iso-time.html> 

•  ISO  10646-1 :  This  is  an  international  Standard  that  specifies  a  character  set  that  relies  on  32  bits, 
includes  approximately  4  billion  characters,  of  which  the  first  65536  are  Unicode,  the  first  256  are 
ISO  8859-1,  and  the  first  128  are  ASCII. 

•  MIME  type:  Multipurpose  Internet  Mail  Extensions  extends  the  format  of  Internet  mail  to  allow 
non-US-ASCII  textual  messages,  non-textual  messages,  multipart  message  bodies,  and  non-US- 
ASCII  information  in  message  headers. 

<http://www.oac.uci.edu/indiv/ehood/MIME/MIME.html> 

•  RFC  1766:  This  Internet  standard  defines  a  language  tag,  referring  to  ISO  639  for  the  language, 
and  to  ISO  3166  for  the  country  code.  <http ://d s . internic . net/rfc/rfc  1 766 . txt> 


•  vCard:  <http://www.imc.org/pdi/>:  This  standard  defines  how  contact  details  for  people  and 

organizations  can  be  represented.  Appendix  D  -  IMS  Learning  Resource  Metadata  XML  Binding 
Specification 

The  following  specification  is  available  from  www.imsproject.org. 
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Appendix  D  -  IMS  Learning  Resource  Metadata  XML 
Binding  Specification 

IMS  Learning  Resource  Metadata 
XML  Binding  Specification 

Version  1 .0 

Copyright  ©  1999  by  EDUCAUSE 
About  This  Document 

Table  of  Contents 

Introduction 


XML  Basics 

Elements 

Element  Contents 
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Introduction 


This  document  describes  the  XML  binding  for  the  IMS  Learning  Resource  Meta-data 
Information  Model.  The  model  is  based  on  the  IEEE  Learning  Technology  Standards 
Committee  (LTSC)  Learning  Object  Meta-data  base  document,  plus  modifications 
approved  by  the  IMS  Technical  Board  and  submitted  to  IEEE.  For  links  to  the  related 
IEEE  documents,  please  see  http ://w w w . imsproj ect . or g/metadata/mdinfoO  1 . html 

XML  Basics 

The  IEEE  conceptual  model  for  metadata  definitions  is  a  hierarchy.  Hierarchical  models 
are  convenient  for  representing  data  consisting  of  many  elements  and  subelements.  XML 
is  perfectly  suited  for  representing  hierarchical  models  such  as  the  IEEE  LOM  Base 
Document.  An  XML  document  is  a  hierarchy  comprised  of  elements  that  have  contents 
and  attributes. 

Elements 

An  element  is  a  component  of  a  document  that  has  been  identified  in  a  way  a  computer 
can  understand.  Each  element  has  a  tag  name.  When  a  tag  name  is  shown  as 
“<TAGNAME>“,  with  less-than  and  greater-than  symbols  before  and  after  the  tag  name, 
it  serves  as  the  start-tag  to  mark  the  beginning  of  an  element.  When  that  same  tag  name 
has  a  forward  slash  “/”  added,  it  serves  as  an  end-tag  such  as  “</TAGNAME>“.  An 
element  may  have  contents  between  its  start  and  end-tags,  and  may  have  one  or  more 
attributes.  When  an  XML  element  has  a  start  and  end-tag  (also  called  an  opening  and 
closing  tag)  with  a  common  name,  it  is  considered  to  be  “well-formed”  XML.  The 
contents  of  an  element  are  placed  between  the  start  and  end-tags  as  shown  below: 

<TAGNAME  >  cont  ent s  < / TAGNAME > 

Element  Contents 

An  element  may  contain  other  elements,  Parsed  Character  Data  (PCDATA),  Character 
Data  (CD  AT  A),  or  a  mixture  of  PCDATA  and  elements.  The  allowable  contents  of  an 
element  are  its  content  model.  PCDATA  really  means  any  character  string  that  does  not 
contain  elements.  PCDATA  is  what  the  bulk  of  elements  will  use  between  their  start  and 
end-tags.  CDATA  is  different  in  that  it  is  a  method  for  adding  any  character  data  that 
should  not  be  processed.  For  example  you  could  add  some  JavaScript  code  instructions 
using  a  CDATA  section.  A  CDATA  section  tells  the  parser  not  to  look  for  any  markup 
until  after  it  locates  the  end  of  the  CDATA  section. 

Element  Attributes 

An  attribute  provides  additional  information  about  an  element.  Attributes  are  a  way  of 
attaching  characteristics  or  properties  to  the  elements  of  a  document.  An  element  may 
have  more  than  one  attribute  and  are  contained  within  the  start  tag  of  an  element. 
Attributes  are  represented  by  an  attribute  name  followed  by  an  equal  sign  and  the 
attribute  value  in  quotation  marks: 

<TITLE>  CLANGSTRING  lang="en-US">Snif fy  the  Virtual 
Rat</LANGSTRING>  </TITLE> 
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In  this  example,  the  TITLE  element  contains  another  element,  the  LANGSTRING 
element.  The  LANGSTRING  element  has  one  attribute  “lang”,  with  the  value  “en-US” 
and  the  contents  of  the  element  being  the  string  “Sniffy  the  Virtual  Rat”. 

Element  Names 

Each  element  has  a  unique  name,  the  tag  name.  XML  is  case-sensitive  in  its  processing 
of  tag  names.  The  IMS  Learning  Resource  Meta-data  XML  binding  specification 
adheres  to  the  following  tag  name  rules: 

•  All  tag  names  will  conform  to  the  rules  for  element  naming  as  given  within  the 
XML  Version  1.0  specification. 

•  Names  beginning  in  “xml”  in  any  case  or  mix  of  cases  are  not  permitted. 

•  The  IMS  binding  will  use  only  upper  case  tag  names.  All  element  names  in  the 
IMS  XML  binding  are  to  be  in  capitals.  This  will  allow  uniform  machine 
conversion  to  a  single  case  should  the  need  arise. 

•  Element  names  may  not  include  words  reserved  by  the  XML  specification.  These 
include: 

DOCTYPE 

ELEMENT 

ATTLIST 

ENTITY 


•  Tag  names  defined  by  the  IMS  binding  may  not  be  redefined. 

Document  Type  Definitions  (DTD) 

The  tag  name,  content  model,  and  attributes  of  elements  are  defined  in  a  Document 
Type  Definition  (DTD)  statement.  This  may  exist  as  an  external  file  or  a  block  of  text 
internal  to  an  XML  document.  Internal  DTDs  are  used  to  override  elements  defined  in 
external  DTD  files,  so  an  internal  DTD  should  be  used  with  care.  The  DTD  defines  the 
elements  that  may  be  used,  and  may  define  the  contents  of  the  elements. 

This  specification  defines  external  DTDs  with  defined  file  names,  specifically  IMS- 
MDOl.dtd  and  IMSCOROl.dtd.  These  file  names  represent  the  1.0  version  of  the  IMS 
Meta-data  and  the  version  1.0  of  the  IMS  CORE  metadata  respectively.  Some  XML 
editors  may  make  use  of  a  DTD  to  help  guide  the  developer  in  creating  the  proper 
elements  at  the  proper  locations  in  an  XML  file.  Other  developers  will  make  use  of 
DTDs  to  validate  their  XML  documents  to  ensure  their  document  is  consistent  with  all  of 
the  element  names  and  locations  defined  in  the  DTD.  An  XML  document  is  valid  if  it 
has  an  associated  document  type  declaration  and  if  the  document  complies  with  the 
constraints  expressed  in  it.  Details  of  the  construction  of  DTDs  are  outside  the  scope  of 
this  document,  but  links  to  the  XML  Version  1.0  specification  and  the  IMS-MDOl.dtd  are 
included  in  the  Appendices  section  of  this  document. 
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Declaring  Element  Contents 

The  information  specifying  the  order  and  usage  of  allowable  contents  for  an  element  are 
its  content  model.  The  content  model  is  declared  in  a  Document  Type  Definition  or  DTD 
(see  below).  The  declaration  of  the  content  model  is  of  the  general  form: 

<! ELEMENT  TAGNAME  (Content  Model) > 

The  DATETIME  element  can  again  serve  as  an  example  of  how  an  element  is  declared 
with  its  content  model: 

<! ELEMENT  DATETIME  (#PCDATA | EXTENSION) *> 

The  vertical  bar  character  “I”  indicates  that  the  metadata  author  may  choose  between  the 
elements.  The  asterisk  “*”  after  the  content  model  means  that  the  #PCDATA  element 
and  the  EXTENSION  element  may  be  mixed  or  optionally  interspersed  with 
subelements.  This  definition  of  the  DATETIME  element’s  content  model  allows  the 
following  XML  fragment  to  exist: 

<DATETIME>1 999-07-23 

<EXTENSION>  CLANGSTRING  lang="en">circa</LANGSTRING> 
</EXTENSION> 

</DATETIME> 

Notice  that  the  EXTENSION  element  is  optional  and  was  used  in  the  example  above. 

The  XML  specification  provides  more  information  about  the  details  for  creating  and 
interpreting  content  models. 

Declaring  Element  Attributes 

An  example  of  how  the  attributes  for  the  element  LANGSTRING  are  declared  in  a  DTD 
is  found  below: 

< ! ELEMENT  LANGSTRING  (#PCDATA | EXTENSION) *> 

< ! ATTLIST  LANGSTRING 
lang  CDATA  #IMPLIED> 

The  first  line  declares  that  there  is  an  element  named  “LANGSTRING”  which  is  allowed 
to  have  PCDATA  and  EXTENSION  elements  as  its  contents.  The  second  line  begins 
with  “!ATTLIST”  to  start  an  attribute  list  declaration  for  the  LANGSTRING  element. 
The  word  “lang”  will  serve  as  the  attribute’s  name.  The  allowable  value  for  this  attribute 
must  be  of  type  CDATA. 

At  the  end  of  the  example  above  is  the  term  #IMPLIED.  It  is  at  this  location  in  the 
attribute  declaration,  where  a  default  value  for  an  attribute  may  be  specified.  It  is  also 
possible  to  use  the  keyword  #REQUIRED  which  would  force  a  lang  value  to  be  supplied 
and  there  would  be  no  default  value.  In  the  example  above,  the  #IMPLIED  designation 
means  that  the  DTD  designer  wants  to  allow  users  to  omit  the  value  for  the  attribute 
without  forcing  a  particular  default  value. 
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Use  of  Attributes 

Within  the  IMS  XML  binding,  the  use  of  attributes  is  reserved  for  information  about  the 
structure  of,  and  source  of  terms  in,  the  metadata  record.  It  is  recommended  that 
attributes  not  be  used  for  information  about  the  resource.  This  IMS  XML  binding 
specification  uses  only  two  element  attributes  (the  “lang”  attribute  and  the  “type” 
attribute)  in  particular  ways  and  for  particular  purposes. 

lang: 

This  attribute  specifies  the  human  language  of  the  contents  of  the  element.  It  is  only  used 
as  an  attribute  of  the  LANGSTRING  element.  The  lang  attribute  may  contain  a  two- 
character  language  code  followed  by  a  two-character  country  code.  For  example: 

<OTHERPLATFORMREQUIREMENTS> 

< LANGSTRING  lang="en-US">Will  not  run  in 
browser . </LANGSTRING> 

</ OTHERPLATFORMREQUIREMENTS> 

The  codes  for  languages  and  countries  are  enumerated  in  the  XML  specification. 

type: 

This  attribute  specifies  the  type  of  string  that  may  be  used  to  identify  the  location  of  a 
learning  resource  as  used  in  the  Location  element.  The  type  attribute  may  be  assigned  the 
value  of  either  “URI”  or  “TEXT”.  These  values  indicate  whether  the  string  used  will  be  a 
simple  textual  description  of  where  a  resource  is  located  or  whether  the  string  represents 
a  resource  available  on  the  Internet  with  a  specific  address  such  as  a  URL.  For  example: 

<  TE  CHN I CAL > 

<FORMAT/> 

<SIZE>1032353</SIZE> 

< LOCATION 

type="URI">http : //www.brookscole . com</LOCATION> 

</TECHNICAL> 

The  codes  for  languages  and  countries  are  enumerated  in  the  XML  specification. 

Lists 

The  metadata  specification  uses  listing  at  multiple  levels  in  the  hierarchy.  A  list  is  a 
repetition  of  the  contents  of  an  element.  In  XML,  this  is  accomplished  by  repeating  the 
containing  element: 

<?xml  version="l . 0"  encoding="UTF-8"?> 

< ! DOCTYPE  RECORD  [ 

< ! ELEMENT  RECORD  (GREETING*) > 

<! ELEMENT  GREETING  (#PCDATA) > 

]> 

<RECORD> 

<GREETING>Hello ,  world ! </GREETING> 

<GREETING>How  are  you?</GREETING> 

</RECORD> 

In  this  example,  the  element  “GREETING”  is  repeated.  Thus  GREETING  is  the 
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containing  element  for  the  repeated  contents  of  “Hello,  world!”  and  “How  are  you?” 
The  notation  for  repetitions  of  an  element  in  a  content  model  follows  the  XML 
specification.  An  asterisk  (*)  specifies  that  none  or  more  repetitions  of  the  element  may 
be  included  in  the  XML  instantiation.  There  are  two  main  types  of  lists:  ordered  and 
unordered. 

Ordered  Lists 

Repeating  the  listed  element  at  its  specific  location  in  the  XML  structure  creates  an 
ordered  list  of  contents.  The  order  of  the  elements  has  significance  as  their  placement  in 
the  XML  file  determines  this.  The  following  is  an  example  of  an  XML  fragment  in 
which  the  EDUCATIONAL  element  contains  an  ordered  list  of 
LEARNINGRESOURCETYPE  (learning  resource  type)  elements: 

<EDUCATIONAL> 

<LEARNINGRESOURCETYPE> 

CLANGSTRING  lang="en">Simulation</LANGSTRING> 

</ LEARN INGRE SOURCE TYPE > 

<LEARNINGRESOURCETYPE> 

<LANGSTRING  lang= " en " >As se s sment </LANGSTRING> 
</LEARNINGRESOURCETYPE> 

</EDUCATIONAL> 


Unordered  Lists 

Repeating  the  containing  element  at  its  specific  location  in  the  XML  structure  creates  an 
unordered  list  of  contents.  The  order  of  the  repetitions  has  no  significance.  For  example: 

<GENERAL> 

<  LAN  GUAGE  >  e  n_U  S  < / LAN GUAGE > 

<  LAN  GUAGE  >  f  r _F  R< / LAN GUAGE > 

</ GENERAL> 

In  this  example,  each  new  instance  of  a  definition  of  a  language  requires  that  the 
LANGUAGE  element  be  repeated.  Whether  an  element  list  should  be  treated  as  ordered 
or  unordered  is  specified  by  the  IEEE  Learning  Object  Meta-data  (LOM)  specification. 

Namespaces 

XML  is  designed  to  allow  individuals  to  create  their  own  element  tag  names.  It  soon 
became  apparent  that  there  could  be  problems  if  different  DTDs  were  used  in  the  same 
document  and  those  DTDs  had  elements  using  the  same  name.  The  XML  Namespace 
recommendation  proposal  specifies  a  way  to  ensure  that  names  from  different  DTDs  can 
be  safely  combined  in  a  single  document. 

XML  namespaces  provide  a  simple  method  for  qualifying  element  and  attribute  names 
used  in  Extensible  Markup  Language  documents  by  associating  them  with  namespaces 
identified  by  URL  references.  The  XML  binding  document  uses  a  default  document  IMS 
namespace  of  http://www.imsproject.org/metadata/.  An  example  namespace  declaration 
for  the  IMS  is  shown  below. 

Namespace  declaration: 
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<RECORD  xmlns="http : / /www . imspro ject . org/metadata/"> 


The  XML  Namespace  document  provides  more  information  about  the  flexible 
capabilities  of  namespaces.  Namespaces  use  their  own  DTD  documents  for  validation. 
In  order  for  any  documents  that  are  based  upon  this  XML  binding  to  find  an  associated 
DTD  such  as  “IMS-MDOl.dtd”,  the  IMS-MDOl.dtd  file  and  the  actual  metadata  record 
must  be  placed  in  the  same  directory  or  the  DTD  must  be  found  at  the  specified  URL. 


Always  make  sure  to  place  the  IMS-MDOl.dtd  and  the 
metadata  record  in  the  same  directory  if  you  wish  to  validate 
the  record  locally. 


Special  Handling  Requirements  for  Meta-data  Elements 

There  are  some  common  structures  that  are  used  more  than  once  within  the  metadata. 

The  use  of  these  common  structures  may  facilitate  the  creation  of  common  data  storage 
structures  in  implementations.  These  structures  have  the  suffix  of  “TYPE”. 
INTERACTIVITYTYPE  is  not  a  common  structure,  even  though  it  ends  in  “TYPE”.  The 
types  defined  in  the  LOM  and  encoded  in  the  XML  are: 

•  LangStringType 

•  DateType 

LangStringType 

LangStringType  denotes  a  string  that  is  encoded  for  a  specific  language  or  other 
interpretable  type.  It  is  of  the  logical  form: 

LangStringType 

LangString 

Language 

String 

It  is  important  to  note  how  the  logical  form  specified  by  the  IEEE  LOM  appears  to  be 
different  from  the  XML  binding  suggested  in  this  document.  In  the  suggested  binding  of 
this  document,  LangStringType  is  not  an  XML  element.  Rather  LangString  is  an  element 
with  a  “lang”  attribute  which  is  used  to  define  the  language  of  a  string  value: 

< LANGSTRING  lang="en">string  value</LANGSTRING> 

The  lang  attribute  can  contain  both  language  and  country  codes  as  defined  in  the  XML 
specification.  Any  element  that  contains  a  LANGSTRING  element  may  contain  multiple 
LANGSTRING  elements  with  each  one  representing  a  different  language 

Each  LANGSTRING  within  an  element  is  considered  to 
contain  the  same  information,  differing  by  language. 

The  XML  1.0  specification  also  allows  the  lang  attribute  to  be  assigned  an  arbitrary  value 
that  is  agreed  upon  by  parties  in  private  use.  These  attributes  are  identified  by  the  prefix 
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“x-”  or  “X-”.  This  practice  is  strongly  discouraged  for  IMS  metadata  records. 

DateType 

DateType  is  a  formatted  date.  There  are  two  subelements  representing  the  two  different 
date  formats  used.  Precise  date  and  time  information  is  formatted  according  to  the  ISO 
8601  specification.  Point  in  time  and  time  duration  information  is  captured  in  the 
DateTime  element.  More  general  date  and  time  information  is  captured  using  the 
Description  element.  A  DateType  may  contain  values  for  both  a  DateTime  and 
Description. 

DateType  has  the  logical  structure  of: 

DateType 

DateTime 

Description 

LangStringType 

LangString 

Language 

String 

It  is  important  to  note  that,  just  as  with  the  LangStringType,  the  logical  form  specified  by 
the  IEEE  LOM  for  DateType  appears  to  be  different  from  the  XML  binding  suggested  in 
this  document.  In  this  binding,  DateType  is  not  an  XML  element.  Rather  Date  is  an 
element  with  two  subelements:  DateTime  and  Description. 

The  DateTime  element  makes  use  of  the  format  dictated  by  the  ISO8601  specification 
Dates  are  captured  using  the  CCYY-MM-DD  form  while  Time  elements  are  specified  as 
hh:mm:ss.  There  is  also  the  ability  to  specify  Time  Zone  Determination  information  by 
adding  “+hh:mm”  to  indicate  differences  in  time  zones.  Both  the  date  and  time  value  are 
combined  using  the  capital  “T”  character  to  separate  them.  Three  examples  of  this  are 
found  below: 

Use  DATETIME  for  precise  dates  and  times.  Use 
DESCRIPTION  for  more  general  date  time  information. 

<DATETIME>1 999-07-2 6<DATETIME> 

<DATETIME>1999— 07— 26T12 : 15 : 35<DATETIME> 

<DATETIME>1999— 07— 26T12 : 15 : 35+01 : 00<DATETIME> 

There  is  a  version  of  the  ISO8601  specification  that  is  available  through  the  W3C  which 
also  specifies  how  a  date  range  is  represented  and  how  date  and  time  duration  is 
accurately  represented.  Readers  may  refer  to  the  ISO8601  specification  available  at: 
http://www.w3.org/TR/NOTE-datetime  for  more  detailed  information  on  the  usage  of 
date  and  time  values. 

Language  elements 

Meta-data  authors  may  specify  a  language  that  will  be  used  as  the  default  language  for 
any  LANGSTRING  elements  that  are  encountered.  This  is  done  by  providing  a  value  for 
the  LANGSTRING  element  that  is  contained  by  the  METAMETADATA  element.  Each 
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individual  occurrence  of  LANGSTRING  may  override  this  default  value  by  declaring  a 

language  and  country  code  using  the  “lang”  attribute. _ 

The  default  language  for  a  record  can  be  specified  in  the 
MetaMetaData  category.  Use  individual  LANGSTRING 
elements  to  override  the  default  language. 


TaxonPath  elements 

In  most  cases,  the  value  of  using  the  TAXONPATH  element  lies  in  the  ability  to  locate 
the  source  of  the  taxonomy.  If  the  source  for  a  TAXONPATH  is  not  provided  or  doesn’t 
map  to  an  existing,  logical  source  then  the  element  should  contain  something  useful 
regarding  how  to  location  information  about  the  taxonomy. 


Always  try  to  provide  a  SOURCE  element  when  using  the 
TAXONPATH  element. 


vCard  elements 

There  are  at  least  two  elements  in  the  IEEE  LOM  that  require  contributing  entity 
information;  elements  LifeCycle.Contribute.Entity  and  MetaMetaData.Contribute.Entity. 
Both  specify  the  vCard  specification  as  the  source  for  representing  these  elements’  data. 

When  using  only  IMS  Core  elements,  the  formatted  name  or  “FN”  element  from  the 
vCard  specification  should  contain  the  name  of  the  individual  contributing  to  the  learning 
resource  of  metametadata  of  the  resource.  If  a  company,  rather  than  an  individual, 
contributed  to  the  resource  or  resource  metametadata,  the  organization  or  “ORG” 
element  from  the  vCard  specification  should  be  used.  This  is  illustrated  below: 


<CENTITY> 

<VCARD> 

BEGIN: vCard 
FN:Lotta  Data 
END : vCard 
</CENTITY> 


As  far  as  most  XML  parsers  are  concerned,  the  information  between  the  <VCARD>  and 
</VCARD>  tags  is  just  a  bunch  of  text.  It  is  up  to  metadata  implementers  to  individually 
determine  how  they  will  process  vCard  information.  The  vCard  specification  allows  for  a 
rich  set  of  information  to  be  captured  as  the  example  below  illustrates.  The  reader  is 
directed  to  the  “Using  the  vCard  Specification”  portion  of  this  document  and  the  vCard 
specification  itself  for  more  details  regarding  its  usage. 

Keywords 

The  elements  General. Keywords  and  Classification. Keywords  are  found  in  the  IMS 
metadata  set.  It  is  expected  that  the  keywords  describing  a  learning  resource  are  likely  to 
be  provided  in  multiple  languages.  To  accommodate  this,  the  IMS  XML  binding 
suggests  that  keywords  and  short,  keyword  phrases  be  represented  as  separate 
LANGSTRING  elements  rather  than  a  comma-delimited  text  string  as  in  the  example 
below: 
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Use  multiple  LANGSTRING  elements  to  represent  keywords 
and  keyword  phrases. 


<KEYWORDS> 

< LANGSTRING  lang="en">operant 
condit ioning< / LANGSTRING> 


<LANGSTRING 
<LANGSTRING 
<LANGSTRING 
<LANGSTRING 
<LANGSTRING 
<LANGSTRING 
</ KEYWORD S> 


lang="en">psychology</LANGSTRING> 

lang="en">simulation</LANGSTRING> 

lang="en">program</LANGSTRING> 

lang="en">shaping</LANGSTRING> 

lang="en">mouse</LANGSTRING> 

lang="en">learn  by  doing</LANGSTRING> 


Extensibility 

Some  metadata  providers  will  find  the  current  element  set  defined  in  the  IMS  metadata  as 
too  restrictive  to  accomplish  their  metadata  purposes.  To  ensure  metadata  extensibility, 
the  IEEE  LOM  Base  Document  requires  that  there  be  no  limit  on  potential  extensions  to 
the  metadata  as  long  as  the  integrity  of  the  specified  metadata  is  not  impaired.  An 
extension  is  the  addition  of  information  to  an  existing  metadata  XML  structure.  There 
are  two  general  ways  to  extend  IMS  metadata: 

1.  One  or  more  elements  may  be  added  to  the  structure  using  elements  defined  in  the 
IEEE  LOM  Base  Document;  and 

2.  One  or  more  elements  may  be  added  to  the  structure  using  elements  that  are  not 
defined  in  the  LOM  specification. 

These  two  types  of  extension  are  defined  as: 

1.  Use  of  elements  from  the  LOM:  The  LOM  specification  contains  some  elements 
with  definitions  that  are  not  specific  for  any  particular  context.  The  context  in 
which  an  element  is  placed  provides  specificity  for  its  definition.  These  elements 
may  be  reused  as  long  as  the  definition  is  not  changed. 

2.  Use  of  elements  not  contained  in  the  LOM  specification:  New  elements  may  be 
introduced  and  used  to  extend  the  structure. 

The  XML  binding  does  not  inhibit  either  of  these  types  of  metadata  extension.  The  XML 
binding  defines  the  Extension  element  as  the  element  used  for  indicating  where  a  set  of 
extension  elements  can  be  found  in  the  metadata  structure.  In  the  IMSMDOl.dtd  file,  the 
EXTENSION  element  exists  in  every  element’s  content  model  allowing  every  element  to 
contain  one  or  more  EXTENSION  elements.  The  only  element  without  an  extension 
capability  is  IDENTIFIER,  as  it  is  a  reserved  word.  The  EXTENSION  element’s  DTD 
declaration  is: 


|Use  the EXTENSION  element  to  extend  the  metadata  structure. 
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<! ELEMENT  EXTENSION  ANY> 


An  example  of  the  inclusion  of  EXTENSION  in  the  content  model  of  element 
COVERAGE  is: 

<! ELEMENT  COVERAGE  (LANGSTRINGTYPE* ,  EXTENSION?) > 

The  use  of  the  EXTENSION  element  is  illustrated  as  follows: 

<COVERAGE> 

<LANGSTRING>1880-1900</LANGSTRING> 

<EXTENSION> 

<ROLE>Date  Range</ROLE> 

</EXTENSION> 

</ COVERAGE > 

The  contents,  but  not  a  content  model,  of  an  extension  must  be  declared  in  an  internal  or 
external  DTD.  Many  extensions  can  be  created  through  the  use  of  existing  elements. 

Care  must  be  used  with  internal  DTDs,  as  they  override  external  DTD  declarations.  The 
contents  of  an  extension  must  obey  the  attribute  and  content  models  of  the  elements 
employed.  New  elements  that  duplicate  the  definitions  of  existing  elements  should  not  be 
introduced. 

Prefacing  the  EXTENSION  element  with  an  appropriate  namespace  may  usefully 
reference  descriptions  of  extensions.  For  example,  a  group  such  as  the  Advanced 
Distributed  Learning  (ADL)  initiative  may  wish  to  add  the  “adl”  prefix  to  an  extension 
element  to  uniquely  identify  ADL  extensions.  An  example  of  this  is  show  below: 

<LEARNINGCONTEXT> 

CLANGSTRING  lang="en">Military  Training</LANGSTRING> 
<EXTENSION  adl :type= "Topic" > 

<TITLE>Roman  military  tactics</TITLE> 

<LANGSTRING  lang="en">This  example  discusses  how 
the  Romans 

defined  many  aspects  of  modern  warfare. 
</LANGSTRING> 

</EXTENSION> 

</LEARNINGCONTEXT> 

This  serves  to  note  the  entire  extension  structure.  Extensions  should  always  be  added  at 
the  lowest  point  (farthest  from  the  root  element)  in  the  hierarchy  possible,  to  the  degree 
that  the  structure  defines  the  meaning  of  the  extension. 


Using  the  vCard  Specification 

The  IMS  XML  binding  uses  the  vCard  specification  wherever  the  Entity  element  is 
defined.  An  Entity,  as  far  as  IMS  metadata  is  concerned,  represents  a  person  or 
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organization.  The  IMS  binding  uses  the  clear  text  form  of  the  vCard  specification.  The 
vCard  specification  defines  the  clear  text  form  as  a  “Simplegram”.  This  is  not  intended 
as  a  complete  description  of  the  vCard  coding;  it  is  intended  to  provide  some  guidelines 
for  simple  cases.  The  vCard  specification  is  located  at  http://www.imc.org/pdi/. 

The  vCard  specification  defines  a  set  of  properties  that  contain  the  information  about  an 
entity.  The  default  character  set  encoding  for  the  vCard  is  7-bit  US-ASCII.  The  default 
character  set  can  be  overridden  for  an  individual  property  using  the  “CHARSET” 
property  parameter.  For  example,  the  ISO  8859-8  or  Latin/Hebrew  character  set  used  in 
an  address  is  specified  by: 

ADR;  CHARSET=ISO— 8859— 8  : ... 

It  is  also  possible  to  set  the  encoding  for  the  entire  record  to  another  encoding.  See  the 
vCard  specification  for  further  instructions.  The  default  language  is  “en-US”,  which  may 
similarly  be  overridden  for  a  property  using  the  “LANGUAGE”  property  parameter. 
Property  names  are  case  insensitive. 

The  general  form  of  the  Simplegram  vCard  encoding  is: 

BEGIN: VCARD 

Items 

END : VCARD 

Items  is  a  list  of  items  separated  by  a  any  valid  line  ending  protocol.  For  example,  in  7- 
bit  ASCII,  the  Carriage  Return  (CR)  character  (ASCII  decimal  13),  the  Line  Feed 
character  (LF)  (ASCII  decimal  10),  the  Carriage  Return  character  followed  by  a  Line 
Feed  character  (CRLF),  or  the  Property  Delimiter  are  line  ending  protocols.  Property 
parameter  substrings  are  delimited  by  the  Field  Delimiter,  specified  by  the  Semi-Colon 
(;)  character  (ASCII  decimal  59).  Each  item  is  of  the  general  form: 

name  rvalue  A; value  B  CRLF 

An  example  of  an  item  with  no  substrings  is  the  formatted  name  property,  FN.  FN  is 
the  full  formatted  name  of  a  person: 

FN:Mr.  James  Q.  Smith,  Jr. 

Some  items  may  have  multiple  properties  or  parameter  substrings.  For  example,  a 
person’s  name,  N,  can  contain  a  Family  Name,  a  Given  Name,  an  Other  Names,  Prefix 
and  a  Suffix.  The  property  value  is  a  concatenation  of  the  Family  Name  (first  field), 
Given  Name  (second  field),  Additional  Names  (third  field),  Name  Prefix  (fourth  field), 
and  Name  Suffix  (fifth  field)  strings  separated  by  the  Field  Delimiter 

N : Smith ; James ;  Q .  ; Mr . ; Jr 

An  unused  substring,  if  not  at  the  end  of  the  list  of  substrings,  is  represented  with  a 
semicolon  only: 

N : Smith; James ; Q . ; ; Jr 
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Vcards  may  be  organized  to  contain  groups.  The  grouping  of  a  comment  property  with  a 
telephone  property  is  shown  in  the  following  example: 

A. TEL; Home : +1-213-555-1234 
A.NOTE:This  is  my  vacation  home. 

Below  are  some  commonly  used  vCard  properties,  with  substrings.  Separate  lines  should 
not  be  used  for  field  substrings,  but  are  used  here  for  clarity: 

Formatted  Name: 

FN : Text  Value 

Example: 

FN:Dr.  Thomas  D.  Wason,  Sr. 

Name: 

N: Family  (Sur)  Name; 

First  (Given)  Name; 

Other  Names; 

Prefix; 

Suffix  CRLF 

Example: 

N : Wason ; Thomas ; D . ; Dr . ; Sr 
Address: 

The  property  value  is  a  concatenation  of  the  Post  Office  Address  (first  field),  Extended 
Address  (second  field),  Street  (third  field),  Locality  (fourth  field,  e.g.,  City),  Region  (fifth 
field,  e.g.,  State),  Postal  (Zip)  Code  (six  field),  and  Country  (seventh  field)  strings: 

ADR:P .O.Box; 

:  Extended  Address 
Street ; 

Locality; 

Region; 

Postal  Code; 

Country  CRLF 

Example: 

ADR:;IMS  Project;1421  Park  Drive; Raleigh; North 
Carolina; 27605-1727 ; United  States  of  America 

Address  Delivery  Label: 

LABEL :  Text 
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Example: 


LABEL ; QUOTED-PRINTABLE : IMS  Pro ject=0A= 

1421  Park  Drive=0A= 

Raleigh,  NC  27605-1727=0A= 

Note  the  use  of  the  escaped  line  feed  (=0A=).  The  property  parameters  are  preceded  by 
semicolon  (;)  after  the  property  name.  They  are  optional,  defining  the  uses  of  the 
Delivery  Label. 

Organization: 

The  property  value  is  a  concatenation  of  the  Organization  Name  (first  field), 
Organizational  Unit  (second  field)  strings.  Additional  positional  fields,  if  specified, 
contain  additional  Organizational  Units: 

ORG : Organization  Name; 

Organizational  Unit [ ; 

Organizational  Unit]  CRLF 

Example: 

ORG: IMS  Project; Meta  Data  Team 

Electronic  Mail: 

EMAIL;  Electronic  Mail  Type: email 

Example: 

EMAIL ; INTERNET : twason@imspro ject . org 
Telephone: 

TEL : telephone  number 

Example: 

TEL : +1  919.839.8187 

All  of  these  previously  described  properties  are  included  in  the  following  example: 

BEGIN :VCARD 

N : Wason ; Thomas ; D . ; Dr . ; Sr . 

FN : Thomas  D .  Wason ,  Ph . D . 

ORG: IMS  Project; Meta  Data  Team 

ADR:;IMS  Project;1421  Park  Drive; Raleigh; North 
Carolina; 27605-1727 ; United  States  of  America 
TEL : +1  919.839.8187 

EMAIL ; INTERNET : twason@imspro ject . org 
LABEL ; QUOTED-PRINTABLE : IMS  Pro ject=0A= 

1421  Park  Drive=0A= 

Raleigh,  NC  27605-1727=0A= 

USA 

END : VCARD 
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Sample  Meta-data  Record 


<?xml  version=“1.0”  encoding=“UTF-8'’?> 

<  1DOCTYPE  RECORD  SYSTEM  “http://www.imsproject.org/XML/IMS-MD01.dtd”> 

<!—  Reference  to  master  DTD  at  IMS  site.  — > 

<!— DOCTYPE  RECORD  SYSTEM  “IMS-MDOl.dtd”  -> 

<!—  Use  this  doc  type  declaration  for  references  to  a  local  dtd.  — > 

<RECORD  xmlns=“http://www. imsproject.org/metadata/”> 

<!—  1999-08-18,  Thomas  D.  Wason:  SniffyOl.xml.  A  complete  meta-data  set.  A  few  empty  fields. 
Located  at  http://www.imsproject.org/xml/Sniffy01.xml  — > 

<!—  The  full  IEEE  -  IMS  Learning  Object  Meta-data  in  XML.  — > 

<MET  AMET  AD  AT  A> 

<C AT ALOGENTR Y  > 

<C  AT  ALOGUE>IMS  -T  est</C  AT  ALOGUE> 

<ENTRY> 

<LANGSTRING>  1999 ,000002</LANGS  TRING> 

</ENTRY> 

</C  AT  ALOGENTR  Y> 

<CONTRIBUTE> 

<ROLE> 

<LANGSTRING  lang=“en”>Author</LANGSTRING> 

</ROLE> 

<CENTITY> 

<!--  Simple  vCard  example  — > 

<VCARD> 

BEGIN:VCARD 

N:Wason;Thomas;D.;Dr.;Sr. 

FN:Thomas  D.  Wason,  Ph.D. 

ORG:IMS  Project;Meta  Data  Team 

ADR:;IMS  Project;1421  Park  Drive;Raleigh;North  Carolina;27605-1727;United  States  of  America 
TEL:+1  919.839.8187 

EMAIL;INTERNET  :twason  @  imsproject.org 
LABEL;QUOTED-PRINTABLE:IMS  Project=OA= 

1421  Park  Drive=OA= 

Raleigh,  NC  27605-1 727=0 A= 

USA 

END:VCARD 

</VCARD> 

</CENTITY> 

<DATE> 

<DATETIME>  1999-08-05</DATETIME> 

</DATE> 

</CONTRIBUTE> 

<METADATASCHEME>IEEELOM:  1 .0</METADATASCHEME> 

<LAN  GU  AGE>en-US</LAN  GU  AGE> 

<!—  English  as  default  meta-data  language.  — > 

</METAMETA-DATA> 

<GENERAL> 

<TITLE> 

<LANGSTRING  lang=“en-US”>Sniffy  The  Virtual  Rat</LANGSTRING> 

<LANGSTRING  lang=“fr”>S niffy  Virtuel  le  Rat</LANGSTRING> 

</TITLE> 

<C AT ALOGENTR Y > 

<C  AT  ALOGUE>ISBN</C  ATALOGUE> 

<ENTRY> 
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<LANGSTRING>0-534-26702-5</LANGSTRING> 

</ENTRY> 

</C  AT  ALOGENTR  Y  > 

<LAN  GU  AGE>en-U  S  </L  AN  GU  AGE> 

<DESCRIPTION> 

<!—  English  description— > 

<LANGSTRING  lang=“en-US”>A  computer  program  that  enables  students  to  explore  the  principles  of 
shaping  and  partial  reinforcement  in  operant  conditioning,  using  a  “virtual  rat"  named  Sniffy.  Each  student 
learns  by  doing-conditioning  his  or  her  own  rat-and  experiences  many  benefits  of  animal  experimentation 
but  none  of  the  drawbacks  associated  with  using  live  animals. </LANGSTRING> 

<!— French  Description  —  > 

<LANGSTRING  lang=“fr”>Un  programme  machine  qui  permet  &#224:  des  &#233;tudiants  d’explorer 
les  prinicples  de  la  formation  et  du  renfort  partiel  dans  l'op&#233;rateur  conditionnant,  utilisant  “  un  rat 
virtuel  “  a  nomm&#233;  Sniffy.  Chaque  &#233;tudiant  apprend  par  le  faire -conditioning  ses  propres  rat-et 
&#233;prouve  beaucoup  d'avantages  rexp&#233;rimentation  animale  de  mais  aucune  des 
inconv&#233;nients  associ&#233;s  &#224;  utiliser  les  animaux  vivants.  </LANGSTRING> 
</DESCRIPTION> 

<KEYWORDS> 

<!— English  Keywords,  unordered  list— > 

<LANGSTRING  lang=“en”>operant  conditioning</LANGSTRING> 

<LANGSTRING  lang=“en”>psychology</LANGSTRING> 

<LANGSTRING  lang=“en”>simulation</LANGSTRING> 

<LANGSTRING  lang=“en”>program</LANGSTRING> 

<LANGSTRING  lang=“en”>shaping</LANGSTRING> 

<LANGSTRING  lang=“en”>rat</LANGSTRING> 

<LANGSTRING  lang=“en”>learn  by  doing</L AN GSTRIN G> 

</KE  Y  W  ORD  S  > 

<KEYWORDS> 

<!— French  keywords,  unordered  list— > 

<LANGSTRING  lang=“fr”>traitement  d'op&#233;rateur</LANGSTRING> 

<LANGSTRING  lang=“fr”>psychologie  </L AN GS TRIN G> 

<LANGSTRING  lang=“fr”>simulation</LANGSTRING> 

<LANGSTRING  lang=“fr”>programme</LANGSTRING> 

<LANGSTRING  lang=“fr”>formation</LANGSTRING> 

<LANGSTRING  lang=“fr”>rat</LANGSTRING> 

<LANGSTRING  lang=“fr”>apprenez  en  faisant</LANGSTRING> 

</KE  Y  W  ORD  S  > 

<COVERAGE> 

<LANGSTRING/> 

</COVERAGE> 

<STRUCTURE> 

<LAN  GS  TRING>Hierarchical</LAN  GSTRIN  G> 

</STRUCTURE> 

<AGGREGATIONLEVEL>2</AGGREGATIONLEVEL> 

</GENERAL> 

<LIFECYCLE> 

<VERSION> 

<LANGSTRING>4.5</LANGSTRING> 

</VERSION> 

<STATUS> 

<LANGSTRING  lang=“en”>Final</LANGSTRING> 

</STATUS> 

<!— Contains  an  unordered  list  of  CONTRIBUTE-> 

<CONTRIBUTE> 

<ROLE> 

<LANGSTRING  lang=“en”>Author</LANGSTRING> 
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</ROLE> 

<!—  Contains  an  ordered  list  of  CENTITY-> 

<CENTITY> 

<VCARD> 

BEGIN:  vCard 
FN:  Lester  Krames 
END:vCard 
</VCARD> 

</CENTITY> 

<CENTITY> 

<VCARD> 

BEGIN:  vCard 
FN:Jeff  Graham 
END:vCard 
</VCARD> 

</CENTITY> 

<CENTITY> 

<VCARD> 

BEGIN:  vCard 
FN:Tom  Alloway 
END:vCard 
</VCARD> 

</CENTITY> 

<DATE> 

<DATETIME>  1995</DATETIME> 

</DATE> 

</CONTRIBUTE> 

<CONTRIBUTE> 

<ROLE> 

<LANGSTRING  lang=“en”>Technical  Implementer</LANGSTRING> 
</ROLE> 

<CENTITY> 

<VCARD> 

BEGIN:  vCard 
FN:Greg  Wilson 
END:  vCard 
</VCARD> 

</CENTITY> 

</CONTRIB  UTE> 

<CONTRIBUTE> 

<ROLE> 

<LANGSTRING  lang=“en”>Publisher</LANGSTRING> 

</ROLE> 

<CENTITY> 

<VCARD> 

BEGIN:  vCard 

ORG:Brooks/Cole  publish  mg;  International  Thomson  Publishing  Company 

END:  vCard 

</VCARD> 

</CENTITY> 

<DATE> 

<DATETIME>  1995</DATETIME> 

</DATE> 

</CONTRIB  UTE> 

</LIFECYCLE> 

<TECHNICAL> 
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<FORMAT/> 

<SIZE>1032353</SIZE> 

<LOCATION  type=“URr’>http://www.brookscole.com</LOCATION> 
<REQUIREMENTS> 

<TYPE> 

<LANGSTRING  lang=“en”>Operating  S  ystem</LAN GS TRING> 

</TYPE> 

<NAME> 

<LANGSTRING  lang=“en”>MS-DOS</LANGSTRING> 

</NAME> 

<MINIMUMVERSION>5.0</MINIMUMVERSION> 

<M  AXIMUM  VERS  ION/> 

</REQUIREMENTS  > 

<INSTALLATIONREMARKS> 

<LANGSTRING  lang=“en”>Load  from  diskette</LANGSTRING> 
</INSTALLATIONREMARKS> 

<OTHERPLATFORMREQUIREMENTS> 

<LANGSTRING  lang=“en”>Will  not  run  in  browser.</LANGSTRING> 
</OTHERPLATFORMREQUIREMENTS> 

<DURATION> 

<DATETIME>0000-00-00T0 1 :20</DATETIME> 

</DURATION> 

</TECHNICAL> 

<EDUCATIONAL> 

<INTERACTIVITYTYPE> 

<LAN  GS  TRING>  Active</L  AN  GS  TRING> 

</INTERACTIVITYTYPE> 

<LE  ARNINGRES  OURCET  YPE> 

<LANGSTRING  lang=“en">Simulation</LANGSTRING> 
</LEARNINGRESOURCETYPE> 

<INTERACTIVITYLEVEL>3</INTERACTIVITYLEVEL> 

<SEM  ANTICDENSITY  >2</SEM  ANTICDEN  SIT  Y  > 
<INTENDEDENDUSERROLE> 

<LANGSTRING  lang=“en”>Learner</LANGSTRING> 
</INTENDEDENDU  SERROLE> 

<!— May  be  an  ordered  list  of  intended  user  roles  with  the  most  relevant  first.— > 
<LEARNINGCONTEXT> 

<LANGSTRING  lang=“en”>Secondary  Education</LANGSTRING> 

</LE  ARNIN  GCONTEXT> 

<TYPIC  ALAGER  AN  GE> 

<L  AN  GS  TRING>  1 2  -99</LAN  GS  TRING> 

</TYPICALAGERANGE> 

<DIFFICULTY  >2</DIFFICULTY  > 

<TYPICALLE  ARNIN  GTIME> 
<DATETIME>0000-00-00T03:00</DATETIME> 

</TYPICALLE  ARNIN  GTIME> 

<DESCRIPTION> 

<LANGSTRING  lang=“en”>Interactive  teaching  of  the  concepts  of  operant 
cond  itio  ning .  </L  AN  GS  TRIN G> 

</DESCRIPTION> 

<LANGU  AGE>en_U  S  </LAN  GU  AGE> 

</EDUCATIONAL> 

<RIGHTS> 

<COST> 

<LANGSTRING  lang=“en”>yes</LANGSTRING> 

</COST> 
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<COPYRIGHTOROTHERRESTRICTIONS> 

<LANGSTRING>yes</LANGSTRING> 

</COP  YRIGHTOROTHERRES  TRICTION  S  > 

<DESCRIPTION> 

<LANGSTRING  lang=“en”>Copyright  1995  Brooks  Cole  Publishing</LANGSTRING> 
<LANGSTRING  lang=“en”>Contact  publisher  to  purchase</LANGSTRING> 

</DESCRIPTION> 

</RIGHTS> 

<RELATION> 

<KIND> 

<LANGSTRING  lang=“en”>IsReferencedBy</LANGSTRING> 

</KIND> 

<RESOURCE> 

<!— IDENTIFIER  reserved  for  later  use.  Do  not  use.— > 

<DESCRIPTION> 

<LANGSTRING  lang=“en”>Companion  book  of  the  same  name.</LANGSTRING> 
</DESCRIPTION> 

</RES  OURCE> 

</RELATION> 

<ANNOTATION> 

<CENTITY> 

<VCARD> 

BEGIN:VCARD 
FN:Stuart  Sutton 
ORG:GEM;Syracuse  University 
END:VCARD</VCARD> 

</CENTITY> 

<DATE> 

<DATETIME>  1999-06-1 0</DATETIME> 

</DATE> 

<DESCRIPTION> 

<LANGSTRING  lang=“en-US”>A  useful  simulation  for  the  student  new  to  concepts  of  behavioral 
science.</LANGSTRING> 

</DESCRIPTION> 

</ANNOTATION> 

<C  L  AS  S IFIC  ATION  > 

<PURPOSE> 

<LANGSTRING  lang=“en”>Discipline</LANGSTRING> 

</PURPOSE> 

<TAXONPATH> 

<SOURCE>Dewey</SOURCE> 

<!— Ordered  list  of  Taxons— > 

<TAXON> 

<ID>300</ID> 

<ENTRY> 

<LANGSTRING  lang=“en”>Social  Sciences</LANGSTRING> 

</ENTRY> 

</TAXON> 

<TAXON> 

<ID>320</ID> 

<ENTRY> 

<LANGSTRING  lang=“en”>Political  Science</L AN GS TRIN G> 

</ENTRY> 

</TAXON> 

</T  AXONPATH> 

<TAXONPATH> 
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<SOURCE>LCSH</SOURCE> 

<!— Ordered  list  of  Taxons— > 

<TAXON> 

<ID>B</ID> 

<ENTRY> 

<LANGSTRING  lang=“en”>Philosophy,  Psychology,  Religion</LANGSTRING> 
</ENTRY> 

</TAXON> 

<TAXON> 

<ID>F</ID> 

<ENTRY> 

<LANGSTRING  lang=“en”>Psychology</LANGSTRING> 

</ENTRY> 

</TAXON> 

<TAXON> 

<ID>180</ID> 

<ENTRY> 

<LANGSTRING  lang=“en”>Experimental  Psychology</LANGSTRING> 
</ENTRY> 

</TAXON> 

</T  AXON  PAT  H> 

<DESCRIPTION> 

<LANGSTRING  lang=“en-US”>principles  of  operant  conditioning</LANGSTRING> 
</DESCRIPTION> 

<KEYWORDS> 

<LANGSTRING  lang=“en">operant  conditioning</LANGSTRING> 
<LANGSTRING  lang=“en'?>psychology</LANGSTRING> 

</KEY  W  ORDS  > 

</CLASSMCATION> 

</RECORD> 


Appendix 
Additional  Resources 
IMS  XML  Documents 

IMS-MDOl.dtd  is  located  at:  http://www.imsproject.org/xml/IMS-MD01.dtd 
IMS-MDOl.xml  is  located  at:  http://www.imsproject.org/xml/IMS-MD01.xml 

IMS  Meta-data  Documents 

The  IMS  Resource  Meta-data  Best  Practice  and  Implementation  Guide  can  be 
found  at:  http://www.imsproject.org/metadata/mdbest01.html 

The  IMS  Learning  Resource  Meta-data  Information  Model  document  can  be 
found  at:  http ://w w w . imsproj ect . or g/met adata/mdinfoO  1 . html 
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ISO/IEC  10646 


ISO  (International  Organization  for  Standardization).  ISO/IEC  10646-1993  (E). 
Information  technology  —  Universal  Multiple-Octet  Coded  Character  Set  (UCS)  - 
-  Part  1:  Architecture  and  Basic  Multilingual  Plane.  [Geneva]:  International 
Organization  for  Standardization,  1993  (plus  amendments  AM  1  through  AM  7). 

Unicode 

The  Unicode  Consortium.  The  Unicode  Standard,  Version  2.0.  Reading,  Mass.: 
Addison-Wesley  Developers  Press,  1996. 
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Appendix  E  -  Reference  Material 

AICC  Learning  Model  Definitions6 


AICC  CMI  TERM 

AICC  “Hierarchy  of 
CBT  Components” 

Curriculum 

COURSE 

Course 

A  complete  unit  of  training.  A  course  generally  represents  what  a  student 
needs  to  know  in  order  to  perform  a  set  of  related  skills  or  master  a  related 
body  of  knowledge. 

Course  structure  provides  a  method  to  group  lessons  into  sequences  for 
assignment.  This  entails  support  for  lesson  hierarchies  which  allow  the 
course  developer  to  define  predecessor  and  successor  relationships." 

BLOCK 

An  arbitrarily  defined  grouping  of  course  components.  Blocks  are  composed 
of  related  assignable  units  or  other  blocks. 

This  is  a  term  used  in  the  AICC  documentCMI  Guidelines  for  Interoperability. 

A  block  may  correspond  to  any  level  of  the  AICC  instructional  hierarchy 
above  lesson,  up  to  and  including  course. 

Chapter 

Sub-Chapter 

Module 

Assignable  Unit 
(AU) 

(aka:  lesson) 

Lesson 

The  smallest  element  of  instruction  or  testing  to  which  a  student  may  be 
routed  by  a  CMI  system.  It  is  the  smallest  unit  the  CMI  system  assigns  and 
tracks. 

A  program  or  lesson  launched  by  the  CMI  system. 

Lesson:  A  meaningful  division  of  learning  that  is  accomplished  by  a  student 
in  a  continuous  effort- that  is  atone  sitting.  That  part  of  the  learning  that  is 
between  designed  breaks.  Frequently  requires  approximately  20  minutes  to 
an  hour. 

OR 

A  grouping  of  instruction  that  is  controlled  by  a  single  executable  computer 
program. 

Or 

A  unit  of  training  thatis  a  logical  division  of  a  subchapter,  chapter,  or  course. 

Topic 

Sequence 

Frame 

Object 

6  Excerpted  from:  DOCUMENT  NO.  CMI001  -  CMI  Guidelines  for  Interoperability,  AICC  ORIGINAL 
RELEASE  DATE  25-Oct-93  Revision  2.1  release  18  lun  98 
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Army  Learning  Structure  Definitions 


COURSE 

A  complete  series  of  instructional  units(phases,  modules  and  lessons)  identified  by  a  common  title  or 
number. 

MODULE 

A-  group  of  lessons  in  an  approved  course  of  instruction;  itcould  consist  of  a  single  lesson  (e.g.,  for 
distance  learning).  Synonymous  with  annex  and  sub-course.  A  module  includes  one  or  more  training 
media/methods  or  combination  thereof. 

LESSON 

The  basic  building  block  of  all  training.  The  level  atwhich  training  is  designed  in  detail.  The  lesson  is 
structured  to  facilitate  learning.  A  lesson  normally  includes  telling  orshowing  the  soldier  whatto  do 
and  how  to  do  it,  an  opportunity  for  the  soldiers  to  practice,  and  providing  the  soldiers  feedback 
concerning  their  performance.  A  lesson  may  take  the  form  of  an  instructor  presented  lesson,  a  SGI 
presented  lesson,  or  a  self-paced  lesson,  such  as  a  correspondence  course  or  CBI  lesson. 

-An  instructor  presented  lesson  or  SGI  presented  lesson  is  documented  as  a  lesson  plan. 

-  A  self-paced  lesson  must  be  of  sufficient  detail  that  the  student  can  learn  the  material  to  the 
established  learning  objective  standard  on  his  own. 

-  An  extension  training  lesson  is  a  self  paced  instructional  program  developed,  reproduced,  and 
packaged  for  distribution  to  soldiers  in  the  field,  these  lessons  consist  of  a  terminal  learning  objective, 
instructional  text,  practice,  and  immediate  feedback  to  the  soldier. 

LEARNING 

OBJECTIVE 

A  precise  three-part  statement  describing  what  the  student  is  to  be  capable  of  accomplishing  in  terms 
of  the  expected  student  performance  under  specific  conditions  to  accepted  standards.  Learning 
objectives  clearly  and  concisely  describe  student  performance  required  to  demonstrate  competency  in 
the  material  being  taught.  Los  focus  the  training  development  on  what  needs  to  be  trained  and 
focuses  student  learning  on  what  needs  to  be  learned. 

Both  terminal  and  enabling  objectives  are  learning  objectives.  Criterion-referenced  Instruction  (CRI)  - 
the  instruction  aimed  at  training  students  to  perform  established  learning  objectives  (performance 
criteria)  to  the  prescribed  standard.  CRI  is  the  selected  instructional  methodology  for  training  within 
the  Army. 

LEARNING 

STEPS 

A  student  activity  that  leads  toward  achievement  of  a  learning  objective.  Learning  steps  are 
determined  when  the  objective  is  broken  down  into  its  component  parts.  Often  an  explicit  hierarchical 
relationship  consisting  of  terminal  learning  objective,  enabling  learning  objective,  and  learning  step  in 
maintained.  Learning  steps  are  identified  and  delineated  in  the  lesson,  training  support  package,  or 
Army  Correspondence  Course  Program  outline  during  the  design  phase.  It  should  be  performance 
oriented. 

MEDIA 

Media  -  word  document,  PowerPointslide  or  presentation,  avi  file  that  is  used  to  assistthe  training 
process. 
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Air  Force  Shared  Content  Object  Model 


Air  University  has  chosen  to  use  the  model  of  Course,  Module,  Learning  Objective,  and  Lesson  which  accommodates  cognitive  levels 
of  instruction  and  testing. 


Marine  Corps  Learning  Object  Taxonomy 


CURRICULUM 

COURSE 

PHASE 

SUBCOURSE  (ANNEX) 

LESSON 

TASK 

LEARNING  OBJECTIVE 
LEARNING  STEP 

Tmedia 


Marine  Corps  Learning  Object 


Copyright  ©  1999  IEEE  Working  Group  Draft  (approved) 


210 


ADL  Learning  Taxonomy  Mapping 
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Appendix  F  -  Document  Change  Summary 

From  0.9.x. 4  to  0.9. x.5  (edits  10-25,26-99) 

•  Added  section  7.6  -  examples  of  SCORM  XML  Metadata  records  derived  from  the  IMS  DTD 
(illustrates  some  prospective  aspects  of  conformance  testing  criteria) 

•  Removed  “old  0.7.3”  metadata  column  in  section  7.3  (now  very  obsolete) 

•  Many  small  edits/cleanups  throughout,  (more  to  be  done  here) 

•  Made  elements  in  section  7.3  the  same  for  content  and  courses  since  they  seemed  so  close 
otherwise.  This  may  change.  See  section  7.6.3. 

•  Revamped  section  7.3  updating  to  IEEE  LOM  3.7  and  adding  all  missing  element  categories 

•  Added  new  references/links  for  related  documents,  especially  in  appendix  D;  combined  appendix 
E  with  D  since  they  are  all  Metadata  related. 

•  Made  parameterstring  under  au. launch  in  CSF  DTD  optional  (thanks  Tyde!) 

•  Added  citations  in  section  2 

•  Added  examples  to  CSF  format,  sections  5.8.1+ 

From  0.9. x5  to  0.9.x. 6  (edits  10-27-99) 

•  Miscellaneous  wordsmithing  in  section  5 

•  Added  missing  text  to  5. 7  Extensibility 

•  Added  missing  text  to  5.8  Conformance  Testing 

•  Added  missing  text  to  6.6  Conformance 

•  Added  missing  text  to  7.5  Conformance 

•  Updated  Appendix  B 

From  0.9.x6  to  0.9.x. 7  (edits  10-30-99) 

•  Very  minor  wordsmithing  sections  2,  3 

•  Changed  section  4  title  to  Definitions 

•  Changed  Compliance  with  conformance  throughout 

•  Fixed  up  numbering  in  section  5 

•  Added  new  section  6.3  as  a  placeholder  for  API  adapter  discussion;  other  sections  renumbered  up 
one. 

From  0.9 .x7  to  0.9.x. 8  (edits  11-1 1-99) 

•  Minor  edits  throughout 

•  Added  section  8  Acronyms 

•  Removed  JSIMS  Example  (Appendix  A)  -  deemed  obsolete 

•  Removed  Section  7.4  (Dictionary)  since  that  has  been  incorporated  within  IEEE’s  table  update 
(3.8)  Renumbered  sections  7.5+  accordingly 

•  Updated  Section  7.3  (table)  to  reflect  explanation  changes  in  IEEE  LOM  version  3.8 
From  0.9. x8  to  0.9.x. 9  (edits  12-6-99) 
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•  Revised  Section  5  as  follows: 

1 .  Removed  “assignments”  from  the  CSF  and  replaced  it  with  “block”  -  this  was  because  it 
appears  that  the  root  node  (formerly  “assignments”)  needs  mostly  all  of  the  same  elements  as 
“block”.  Since  “blocks”  nest  n  deep,  it  seemed  to  make  sense  to  not  differentiate  between 
root  and  nodes;  i.e.,  they  should  be  the  same  thing.  Note  that  this  does  not  appear  to  be  the 
case  with  nodes  (blocks)  and  leaves  (aus)  since  there  are  differences. 

2.  Removed  “content”  element  (and  its  sub-elements)  on  the  basis  that  the  data  that  would  be 
contained  in  these  elements  should  be  available  within  externally  referenced,  LOM -based 
metadata  records. 

From  0.9.x. 9  to  0.9.X.10  (edits  12-7-99) 

•  Section  5.6,  5.10  and  figure  5.4.2a:  renamed  element  “score”  to  “masteryScore”  and  eliminated 
sub-elements  “mastery”,  “maximum”,  and  “minimum”  since  these  elements  don’t  belong  here 
(they  are  in  the  CMI  data  model  and  have  no  meaning  here;  however,  “masteryScore”  does  have 
context-specific  value.  This  element  defines  the  mastery  score  the  student  must  achieve  in  this 
course  context,  which  overrides  whatever  default  mastery  value  an  au  might  have  defined. 

From  0.9.x.  11  to  1.0 

•  Miscellaneous  minor  edits  throughout 

•  Added  sections  1.1,  1.2,  1.3 

•  Section  6.1  modified  figure  6.1. a  showing  content/au 

•  Added  examples  to  6.3,  6.4 

•  Added  Section  6.6  -  further  defining  content  as  Assignable  Units  (renumbered  6.7+) 

•  Added  data  model  tables 

•  Added  section  7.4  Stand-Alone  XML  Metadata  Records 

•  Added  section  7.5  XML  Schema,  Namespaces  and  Extensibility 

•  Renumbered  old  7.4+ to  7.6+ 

•  Changed  appendices  sequence;  moved  dtd  to  appendix  A 

•  Minor  edits  throughout  sections  1  and  2 

•  Incorporated  3.5  into  3.4 

•  Added  section  8  examples 

•  Added  examples  and  ref  tables  throughout 

•  General  editing 

•  Editing  Throughout. 
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